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