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

    What's involved in fixing VLAN's?

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    18 Posts 6 Posters 4.3k 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.
    • M
      markuhde
      last edited by

      Okay, so while I'm waiting on this to be fixed - since it doesn't seem to be an easy or quick fix likely to happen anytime soon - does anyone know a way to traffic shape just my WAN port (since it's on a physical interface)? Basically, I just want to prioritize ACK's at least so that the upstream can't get saturated and force the downstream to a crawl on the extremely off-balance 10 Mbps/768 kbps ADSL connection

      1 Reply Last reply Reply Quote 0
      • rcfaR
        rcfa
        last edited by

        @cmb:

        It's not fixing VLANs, it's fixing ALTQ. It's not designed to work on virtual interfaces, we have a kernel patch that accommodates that which has to be adapted every base version change.

        Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?
        It's kind of strange that someone fixes it, and they keep going on with the same old…
        ...at least that's what it sounds like.

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

          Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?

          FreeBSD's pf is several years behind OpenBSD's.

          I wish FreeBSD would make "pf" their primary packet-filter … as Apple has apparently done recently. This might also encourage them to fix some of the long-standing issues of pf under FreeBSD, e.g. GRE+NAT (for PPTP), NAT before IPsec etc

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            @dhatz:

            I wish FreeBSD would make "pf" their primary packet-filter … as Apple has apparently done recently. This might also encourage them to fix some of the long-standing issues of pf under FreeBSD, e.g. GRE+NAT (for PPTP), NAT before IPsec etc

            Most of those issues have nothing to do with FreeBSD, they're the same in Open to this day. They do at least have a NAT+IPsec work around for isakmpd, but GRE and other things are no different there.

            @rcfa:

            Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?
            It's kind of strange that someone fixes it, and they keep going on with the same old…
            ...at least that's what it sounds like.

            We're doing what we can to get more involved upstream so we don't have to keep patching and re-patching and re-patching.

            1 Reply Last reply Reply Quote 0
            • M
              markuhde
              last edited by

              Well I see the bug report says it's fixed today, thanks guys for your awesome work! I'm gonna need to become a paid member soon! Way cheaper than buying commercial firewall products!

              1 Reply Last reply Reply Quote 0
              • M
                markuhde
                last edited by

                Hi, I just thought I'd bump this so anyone in my shoes can know not to upgrade snapshots right now - I haven't upgraded thankfully because I subscribed to the bug report, but there was a note posted to the bug report that the patch to fix this has been reverted due to it causing problems with connecting to attached managed switches.

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

                  That is correct. The changes for ALTQ broke communication for VLANs in some settings, so they had to be reverted.

                  The ticket will be updated when a new fix is found.

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  1 Reply Last reply Reply Quote 0
                  • M
                    markuhde
                    last edited by

                    Thanks jimp, for what it's worth I'm seeing no problems at all other than I think the queue status is under-reporting the amount of traffic in the queues (for example, HTTP on the staff network goes into QOthersHigh - on the guest network it goes to Squid and seems to show up on QLink). Yet, during a speed test, seeing the full 10mbps down of the DSL line, QOthersHigh on LAN (the staff network) will only show like 2-3Mb in the queue status?

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

                      Perhaps you're not on a current build. Shaper rules would fail to apply to a vlan interface at all, stating that they do not support altq.

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 0
                      • M
                        markuhde
                        last edited by

                        Correct, I'm not - that's my point :) I made sure not to upgrade because I stayed subscribed to the ticket. What I was wondering was what didn't work with the fix - the system I have is working perfectly?

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

                          We had one developer and a couple customers find themselves in situations where some devices would be unreachable on the VLAN. ARP would go out but never reply. Meanwhile other hosts could reach them without issue. Backing out the VLAN changes made it work again.

                          Not sure exactly what was different about the hosts that could not be reached, but the person who would be able to debug that in depth is out on vacation for another week yet so we backed it out for now.

                          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                          Need help fast? Netgate Global Support!

                          Do not Chat/PM for help!

                          1 Reply Last reply Reply Quote 0
                          • M
                            markuhde
                            last edited by

                            Hmmm, that makes me wonder if I should update and give up traffic shaping. I haven't had any issues that I've been able to observe, but this is at a public place that sees hundreds of users on their Wi-Fi in a week, if even a few would have issues, perhaps it's better to not have traffic shaping… Thanks.

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

                              Well this is also only the ALTQ shaper that is affected (hfsc, priq, cbq, etc), afaik limiters worked fine. Many things can be expressed similarly in limiters.

                              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                              Need help fast? Netgate Global Support!

                              Do not Chat/PM for help!

                              1 Reply Last reply Reply Quote 0
                              • M
                                markuhde
                                last edited by

                                Okay, so the big thing for me is to prioritize upstream ACK's. Is there any way to do this without traffic shaping? The campground this is installed at is in the middle of a large event now, and while I've heard no Wi-Fi complaints, the occasional "can't connect" amidst a large group of people who CAN connect would probably go unreported. Thus, I'm planning to update and remove the shaping IFF I can keep a couple upload-heavy users from having the ability to bring down the entire connection (It's very off-balance, 10 Mbps downstream, 768 Kbps upstream).

                                Well, that and concerns I won't be able to get the new PBI of FreeRadius 2 working if I update

                                1 Reply Last reply Reply Quote 0
                                • T
                                  trunix
                                  last edited by

                                  Running through the appropriate traffic shaping wizard will set up a prioritized ACK queue for the WAN interface (qACK).  I think you'll need to select some type of traffic to utilize the ACK queue otherwise it'll just fill up the default queue.  All this can be done very easily within the wizard.  Are you worried about a small subset of camp customers uploading large YouTube videos and ruining it for everyone else?  Why not just prioritize HTTP & HTTPS traffic?  I find that when people complain about "the Internet" not working it's usually due to some slow loading webpage.

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.