[LibreQoS] how are you doing on ipv4 address supply?

[Robert Chacón]

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 at 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 at 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 at 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 at 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 at 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 at lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>>>
>>>> _______________________________________________
>>>> LibreQoS mailing list
>>>> LibreQoS at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>>
>>> _______________________________________________
>>> LibreQoS mailing list
>>> LibreQoS at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>
>>
>>
>> --
>> Robert Chacón
>> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>


-- 
Robert Chacón
CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221026/62696bcf/attachment.html>