What's involved in fixing VLAN's?
-
This topic is partially to draw attention to bug 2349 https://redmine.pfsense.org/issues/2349 - but more to ask what it realistically will take to fix this bug? The bug description makes it sound like a core functionality got broken in FreeBSD 8.3 and fixing this bug will be a rather long ordeal that may or may not even happen? To be honest, I'm just learning about FreeBSD (just setup a FreeBSD web server last night as a test/sandbox - something I've always used Linux for!) and I'm also just starting to learn more about using VLAN tagging. This sounds more like an underlying OS problem or change, and I'm trying to understand it better not only for pfSense but also for using FreeBSD in general. I've been very impressed with the stability and uptime I'm getting on pfSense, even the 2.1 snapshots, and want to learn more advanced networking.
I do run a small business, but most of my clients are just using off-the-shelf routers plugged in with maybe a couple extra access points. I'm learning larger (thus, more profitable) installs starting with a camp that's friendly to me (that's where the pfSense 2.1 install is) and a couple other friendly clients of mine. Thus, the need to learn things like VLAN tagging, QoS traffic shaping (the feature I'm anxiously awaiting patiently being able to use in pfSense 2.1 - the major bug was fixed and now 2349 keeps it from working), RADIUS authentication, 802.1x, etc.
-
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.
-
Ah, so basically FreeBSD doesn't actually support traffic queues on virtual interfaces, thus every release of FreeBSD requires the pfSense team to add this functionality?
Sorry if that's not exactly correct, that's why I'm asking - I'm trying to learn this. My initial idea was I was going to give up on pfSense on this install, and just install FreeBSD 9.0 and learn to configure the functionality I needed myself - I came here thinking pfSense was nothing more than a configuration GUI on top of FreeBSD. I'm starting to learn that pfSense really is in many ways it's entirely own software project, with a lot of added functionality one can't get simply by installing ports on FreeBSD. Impressive stuff and thank you guys very much for all you do!
-
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
-
@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. -
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
-
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.
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.
-
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!
-
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.
-
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.
-
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?
-
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.
-
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?
-
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.
-
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.
-
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.
-
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
-
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.
