I think it could definitely be helpful. Cambium's Bequant-based QoE handles MPLS parsing. Like you said MPLS tends to be a holdup for a lot of people looking at Preseem. And it would make shaping at sites possible. You said it looks reasonably straightforward to implement within cpumap-pping/xdp-cpumap-tc? If you'd need more time to dedicate to it to explore that more, let us know what a fair feature bounty would be for it. =) I can see it helping a lot of operators. On Wed, Oct 26, 2022 at 1:33 PM Herbert Wolverson via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > The main reason I was asking about MPLS is that it looks pretty easy to > extract the data, and I've seen a bunch of people on the WISP Talk FB group > complaining about having to de-encapsulate before they pass things through > Preseem. Where I could see that being most useful is if you have a shaper > at a tower (rather than just the one), and want to shape your backhaul > directly. I'll keep it on the "things to play with" list. :-) > > We ran MPLS/VPLS for a while; we were pretty surprised when our network > sped up a lot when it was removed! (Routers got really good at routing, and > it's often faster than parsing a label these days). It also made it easier > for the other techs to diagnose faults, MPLS never seemed to "click" for > them. > > On Wed, Oct 26, 2022 at 2:15 PM Robert Chacón < > robert.chacon@jackrabbitwireless.com> wrote: > >> We use MPLS (VPLS tunnels back to core) with L2 isolation and DHCP >> snooping everywhere. >> It decapsulates at our core so we don't need MPLS parsing for LibreQoS in >> our case. >> It works well and minimizes the number of RFC6598 CG-NAT clients behind >> public addresses. >> I'd prefer simple routing, but with IPv4 exhaustion - that would lead to >> a lot of unused RFC6598 addresses (and hence high CG-NAT ratios). >> Many clients on one CG-NAT address leads to a lot of problems with >> services like Amazon Prime. >> I'm hopeful we can switch to VXLAN as Dan suggested. It could be a great >> alternative to VPLS/MPLS. >> >> On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS < >> libreqos@lists.bufferbloat.net> wrote: >> >>> MPLS is great for those that have dedicated engineering staff or hire a >>> consultant to help out. It's a real PITA when the business is primarily >>> techs and they have no idea how to solve an issue. I've been pushing for >>> vxlan/evpn or srv6 for a while as a way to simplify the model. 'wisp' >>> focused gear just isn't there yet though. high hopes for mikrotik's >>> support for vxlan to get hardware acceleration. >>> >>> On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS < >>> libreqos@lists.bufferbloat.net> wrote: >>> >>>> Actually had a conversation with our primary upstream provider >>>> yesterday about IPv6 (and why >>>> they won't provide it to us). One of their lead engineers, once plied >>>> with beer, said that every >>>> time they've deployed it they get 99% of it working well and 1% of >>>> things mysteriously >>>> stop working, or go wonky. That was similar to our experience a few >>>> years ago. It mostly >>>> helped a lot, but chasing down the "hey, this advertises a v6 address >>>> and doesn't actually >>>> support it" issues drove us crazy. >>>> >>>> Right now, we don't have enough IPv4 addresses, but that's being >>>> rectified. We mostly >>>> do CGNAT and 10.64 addresses in the meantime, with public IPs assigned >>>> where they >>>> are needed (mostly through a tunnel setup to avoid subnetting waste). >>>> Tunnels are a pain, >>>> but they work (once you chase down all of the MTU issues). >>>> >>>> Which reminds me, I have "can we support MPLS?" on my crazy notes list. >>>> I know that >>>> Preseem and similar don't try, but we're already reading deeply enough >>>> into the ethernet >>>> header that saying "this is an MPLS label, advance 4 bytes", "this is a >>>> VPLS label, advance >>>> X (I forget) bytes" looks do-able. [Note, I personally don't enjoy >>>> MPLS. It's handy when >>>> you want to pretend to have a flat network on top of a large routed >>>> network - and some >>>> WISP consultants absolutely swear by it - but my experience is that you >>>> are adding >>>> complexity for the sake of it. Routing works remarkably well.] >>>> >>>> On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS < >>>> libreqos@lists.bufferbloat.net> wrote: >>>> >>>>> in my continued rip-van-winkle, living in the third world (california) >>>>> way, I am curious as to how y'all are managing your >>>>> ipv4 address supply and if you are deploying ipv6 to any extent? >>>>> >>>>> In all this discussion of multi-gbit fiber, my own direct experience >>>>> is that AT&T's fiber rollout had very flaky ipv6, and more and more >>>>> services (like starlink) are appearing behind cgnats, which have their >>>>> own capex and opex costs. >>>>> >>>>> I see a lot of rfc1918 being used as the operational overlay >>>>> elsewhere, tons of tunnels, also. >>>>> >>>>> -- >>>>> This song goes out to all the folk that thought Stadia would work: >>>>> >>>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz >>>>> Dave Täht CEO, TekLibre, LLC >>>>> _______________________________________________ >>>>> LibreQoS mailing list >>>>> LibreQoS@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/libreqos >>>>> >>>> _______________________________________________ >>>> LibreQoS mailing list >>>> LibreQoS@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/libreqos >>>> >>> _______________________________________________ >>> LibreQoS mailing list >>> LibreQoS@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/libreqos >>> >> >> >> -- >> Robert Chacón >> CEO | JackRabbit Wireless LLC >> > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > -- Robert Chacón CEO | JackRabbit Wireless LLC