On Wed, Jul 26, 2023 at 11:10 AM Juliusz Chroboczek wrote:
> > CONNECT-UDP
>
> Come on, David, we all know that MASQUE is an elaborate practical joke.
> With draft-asedeno-masque-connect-ethernet, you guys are obviously trying
> to see how far you can go before people realise you're taking the
> CONNECT-UDP
Come on, David, we all know that MASQUE is an elaborate practical joke.
With draft-asedeno-masque-connect-ethernet, you guys are obviously trying
to see how far you can go before people realise you're taking the piss.
> (You could even perform dichotomy there to measure the exact
On Wed, Jul 26, 2023 at 5:18 AM Juliusz Chroboczek wrote:
> > While you're absolutely right that this MUST NOT happen, in practice it
> does.
>
> I think we're in at least partial agreement. The point I'm making is that
> this configuration is not something that's supported by IP, and that VPN
> While you're absolutely right that this MUST NOT happen, in practice it does.
I think we're in at least partial agreement. The point I'm making is that
this configuration is not something that's supported by IP, and that VPN
implementations that cause MTU blackholes are quite simply buggy.
On Wed, Jul 26, 2023 at 02:02:14PM +0200, Juliusz Chroboczek wrote:
> > Uups, nevermind this. I was looking at the other node's hellos. The
> > neighbour relationship goes down properly as you'd expect.
>
> Merged into master. Shall I release 13.1?
I think you mean 1.13, but that's ready
> Uups, nevermind this. I was looking at the other node's hellos. The
> neighbour relationship goes down properly as you'd expect.
Merged into master. Shall I release 13.1?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I can observe (some) hellos using the padding depending on the option
> setting. Problem is when I force the interface MTU to 1280 instead of the
> initial 1420 the padded hellos get dropped and don't reach the other side
> as you'd expect, but the regular sized hellos still make it through and
On Thu, Jul 20, 2023 at 02:40:40PM +0200, Daniel Gröber wrote:
> On Wed, Jul 19, 2023 at 11:25:52PM +0200, Juliusz Chroboczek wrote:
> > Could you please test the new branch "probe-mtu"? It's now using the
> > IPV6_DONTFRAG cmsg in sendmsg, so it's enough to say
> >
> > default probe-mtu
Hi Juliusz,
On Wed, Jul 19, 2023 at 11:25:52PM +0200, Juliusz Chroboczek wrote:
> Could you please test the new branch "probe-mtu"? It's now using the
> IPV6_DONTFRAG cmsg in sendmsg, so it's enough to say
>
> default probe-mtu true
>
> (No global options, only per-interface options.)
I
Daniel,
Could you please test the new branch "probe-mtu"? It's now using the
IPV6_DONTFRAG cmsg in sendmsg, so it's enough to say
default probe-mtu true
(No global options, only per-interface options.)
-- Juliusz
___
Babel-users mailing list
> To test dont-fragment I first set it to disabled and changed the
> (wireguard) interface MTU from 1420 to 1280 at runtime. Doing this I can
> observe babel hellos being fragmented in tcpdump.
>
> When setting dont-fragment true this trick doesn't work and the neighbour
> relationship to the
Hi Juliusz,
While my (now fixed) tunnel stacking mitigation works for locally generated
wg packets it doesn't when they are being routed for another host on the
(ethernet) network. This was what motivated the MTU probing idea in the
first place.
I belive the probe-mtu option is still useful in
Hi,
after some more testing and tcpdumping I have to revise my theory of what's
going on, turns out Juliusz was right all along (as usual :)
On Mon, Jul 17, 2023 at 02:26:40AM +0200, Daniel Gröber wrote:
> Let me try to give some more context:
>
> My mesh network deploys two wg tunnels per
On Tue, Jul 18, 2023 at 03:37:14PM -0700, David Schinazi wrote:
> [ ... an hour passes by with this email half written ... ]
>
> Oh, and in the meantime Juliusz just went ahead and implemented probe-mtu.
> Nicely done, sir! Looking at the PR it validates that the kernel-provided
> MTU gets
Hi Juliusz,
While you're absolutely right that this MUST NOT happen, in practice it
does. A rare scenario is when routes change deep in a network causing the
e2e PMTU to change without the link MTU on the endpoints observing any
change. This phenomenon happens much more commonly on tunnels when
Completely untested. Please checkout the branch "probe-mtu", then say
this in your config file:
dont-fragment true
default probe-mtu true
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> RFC 2460: "link MTU - the maximum transmission unit, i.e., maximum packet
>>size in octets, that can be conveyed over a link."
> I read this as "link MTU" being the maximum packet size that you could ever
> hope to be able send but the link technology could very well not allow the
On Mon, Jul 17, 2023 at 11:41:01AM +0200, Juliusz Chroboczek wrote:
> >> Sorry, I wasn't clear. IP requires every link to have a well-defined
> >> MTU: all the nodes connected to a link must agree on the link's MTU.
>
> > I don't think that can be true either. PMTU can vary and paths can be
> >
Hi,
I also wish there was some form of ensuring a path with a minimum MTU.
My use case is providing a minimum MTU for VXLAN overlay networks in
very heterogeneous networks consisting of different tunnel mechanisms
(gre, wireguard, via v4 and v6), direct ethernet links and ptp connections.
>> Sorry, I wasn't clear. IP requires every link to have a well-defined
>> MTU: all the nodes connected to a link must agree on the link's MTU.
> I don't think that can be true either. PMTU can vary and paths can be
> asymmetric so two nodes could very well see different MTUs across the
>
On Mon, Jul 17, 2023 at 12:47:30AM +0200, Juliusz Chroboczek wrote:
> >> IP does not support variable MTU links.
> >
> > Excuse me, but that's plain false. IP was designed in an environment where
> > (non-ethernet) networks with various MTU standards were commonplace
>
> Sorry, I wasn't clear.
>> IP does not support variable MTU links.
>
> Excuse me, but that's plain false. IP was designed in an environment where
> (non-ethernet) networks with various MTU standards were commonplace
Sorry, I wasn't clear. IP requires every link to have a well-defined
MTU: all the nodes connected to a
On Sun, Jul 16, 2023 at 11:43:44PM +0200, Juliusz Chroboczek wrote:
> IP does not support variable MTU links.
Excuse me, but that's plain false. IP was designed in an environment where
(non-ethernet) networks with various MTU standards were commonplace and
this is very much supported. Why else
> Problem is when the underlay L3 network is composed of more tunnels and not
> 1500 MTU ethernet links, then at each hop the path MTU could be reduced by
> the tunnel overhead again and again and again (across the entire
> path). Hence no predictable MTU I can deploy across all my interfaces
>
Hi Juliusz,
On Sun, Jul 16, 2023 at 09:22:40PM +0200, Juliusz Chroboczek wrote:
> > I've been running babel on top of my wireguard IPv6 network for a while now
> > and I have a problem that keeps biting me and I can't find a good solution
> > for: babel is oblivious to a link's MTU and picks
> I've been running babel on top of my wireguard IPv6 network for a while now
> and I have a problem that keeps biting me and I can't find a good solution
> for: babel is oblivious to a link's MTU and picks paths that involve
> wireguard-in-wireguard tunnels even though paths without this stacking
Hi babelers,
I've been running babel on top of my wireguard IPv6 network for a while now
and I have a problem that keeps biting me and I can't find a good solution
for: babel is oblivious to a link's MTU and picks paths that involve
wireguard-in-wireguard tunnels even though paths without this
27 matches
Mail list logo
