From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D0A8F3B2A4 for ; Wed, 26 Oct 2022 15:15:45 -0400 (EDT) Received: by mail-ed1-x52a.google.com with SMTP id t15so8528718edd.4 for ; Wed, 26 Oct 2022 12:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jackrabbitwireless.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k16Qf69h2akIFy0DN9IGhAoDFVycFQ8RFfAK8ezv23k=; b=NU0QK0SDbQ7icEoojlYTBu3bg6mWv5Gsu0JtZHRLN6CwnQmu93k2RKMUwggVrlGmw9 fNFDaZPmuQGOMUXWi4n+CL9dQfda0Kp4kjRc9wRzeKtZ0FvR6xbgZzCU5Ab9DtE2eXQs bY9hWh975JWYUlCFyhtbe3zPmcxS+ykxMLAEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k16Qf69h2akIFy0DN9IGhAoDFVycFQ8RFfAK8ezv23k=; b=gtrseVRzCoI6eMMWLKyLOesnS1YYnk6PrCimvAz9lhUrhFTPORHfgADKS8XaUut6S+ JwHb9AzhiFkGIKvCj2vtgSFjwZYCtz+WMptoO8blpJA0AqIV2gIjI2UouJ9FYZR8YRjz h41UJAW8tUUc581kmbd4ZYrs0Qb/59Qr+Qgpru8pz1qG2kamVouUXfcN7Z7EzENAf9bk b7ptweF0pFU6R73OddEFxJH+mYVv1BtqaWAuNBAZKd093gIrEX+WaiIJI0utHoYVdFV7 Im7CwN31Ex504V3kJf6ZU5Dn+jc/lhan/nssBAd8balznUb7cn+Uy3UL3ZVw3TmDPlek iGlw== X-Gm-Message-State: ACrzQf360gsqRcnXXwzYagLjICtg4Ge3FNr0T6mob2d+97x3g2+3tABg 7Ym3thErSgb0OQTXNUk02MOLnVrreebFNIHDkt0k8A== X-Google-Smtp-Source: AMsMyM6uWZH3gfpF2ra4KnPpE75JQXwaBH9QkSA9MlMnh3KtNKlxrdRqkQoveJJUFkMkCDpG6oFnxPoXAIzcU0PlPjs= X-Received: by 2002:a05:6402:4006:b0:461:f4e2:82e0 with SMTP id d6-20020a056402400600b00461f4e282e0mr12903663eda.68.1666811744535; Wed, 26 Oct 2022 12:15:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Robert_Chac=C3=B3n?= Date: Wed, 26 Oct 2022 13:15:33 -0600 Message-ID: To: dan Cc: Herbert Wolverson , libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000f0e05705ebf4d923" Subject: Re: [LibreQoS] how are you doing on ipv4 address supply? X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2022 19:15:46 -0000 --000000000000f0e05705ebf4d923 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 fo= r > 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 thing= s >> mysteriously >> stop working, or go wonky. That was similar to our experience a few year= s >> ago. It mostly >> helped a lot, but chasing down the "hey, this advertises a v6 address an= d >> 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-6981366= 665607352320-FXtz >>> Dave T=C3=A4ht 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 > --=20 Robert Chac=C3=B3n CEO | JackRabbit Wireless LLC --000000000000f0e05705ebf4d923 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We use MPLS (VPLS tunnels back to core) with L2 isola= tion 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 exhausti= on - that would lead to a lot of unused RFC6598 addresses (and hence high C= G-NAT ratios).
Many clients on one CG-NAT address leads to a lot = of problems with services like Amazon Prime.
I'm hopeful we c= an switch to=C2=A0VXLAN as Dan suggested. It could be a great alternative t= o VPLS/MPLS.

On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS <= ;libreq= os@lists.bufferbloat.net> wrote:
MPLS is great for those that have = dedicated engineering staff or hire a consultant to help out.=C2=A0 It'= s a real PITA when the business is primarily techs and they have no idea ho= w to solve an issue.=C2=A0 =C2=A0I've been pushing for vxlan/evpn or sr= v6 for a while as a way to simplify the model.=C2=A0 'wisp' focused= gear just isn't there yet though.=C2=A0 high hopes for mikrotik's = support for vxlan to get hardware acceleration.=C2=A0 =C2=A0

On Wed, Oct 26,= 2022 at 10:05 AM Herbert Wolverson via LibreQoS <libreqos@lists.bufferbloat.ne= t> wrote:
Actually had a conversation with our primary upstrea= m provider yesterday about IPv6 (and why
they won't provide i= t to us). One of their lead engineers, once plied with beer, said that ever= y
time they've deployed it they get 99% of it working well an= d 1% of things mysteriously
stop working, or go wonky. That was s= imilar 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= 9;s being rectified. We mostly
do CGNAT and 10.64 addresses in th= e meantime, with public IPs assigned where they
are needed (mostl= y 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", &= quot;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 i= t. Routing works remarkably well.]

On Tue, Oct 25, 2022 at 10:30 P= M 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-FXt= z
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos


--
Robert Chac=C3=B3n
CEO | JackRabbit Wireless LLC
--000000000000f0e05705ebf4d923--