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

[Robert Chacón]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221026/31e68c67/attachment.html>