> From: Saku Ytti
> Sent: Tuesday, March 12, 2019 6:14 PM
>
> On Tue, Mar 12, 2019 at 8:09 PM wrote:
>
> > Yes right, but the lookup principle is the same either you look at IPv6 flow
> label or you look at the Entropy label.
>
> Correct, FAT, Entropy and IPv6 Flow Label are all in principle
On Tue, Mar 12, 2019 at 8:09 PM wrote:
> Yes right, but the lookup principle is the same either you look at IPv6 flow
> label or you look at the Entropy label.
Correct, FAT, Entropy and IPv6 Flow Label are all in principle same, a
way for source node to communicates what constitutes a flow.
> From: Saku Ytti
> Sent: Tuesday, March 12, 2019 6:01 PM
>
> On Tue, Mar 12, 2019 at 7:55 PM wrote:
>
> > This was on Trio and sorry I should have clarified we did test with default
> L3+L4 keys on MPLS labelled packets -default in Junos (as baseline).
> > And then repeated the test using
On Tue, Mar 12, 2019 at 7:55 PM wrote:
> This was on Trio and sorry I should have clarified we did test with default
> L3+L4 keys on MPLS labelled packets -default in Junos (as baseline).
> And then repeated the test using flow labels -which forced Trio to ignore the
> L3+L4 keys and act
Hey Saku,
> From: Saku Ytti
> Sent: Tuesday, March 12, 2019 11:54 AM
>
> Hey Adam,
>
> > We did this exact testing a while back on Juniper 2nd and 3rd gen PFEs.
> > The results showed it doesn't matter a tiny bit whether you do 5-tuple hash
> or use flow label.
> > So the bottom line is on
Hey Adam,
> We did this exact testing a while back on Juniper 2nd and 3rd gen PFEs.
> The results showed it doesn't matter a tiny bit whether you do 5-tuple hash
> or use flow label.
> So the bottom line is on modern NPUs it doesn't really matter.
Does PFE mean PE or Trio? What exactly did you
> Töma Gavrichenkov
> Sent: Friday, March 8, 2019 5:07 PM
>
> On Fri, Mar 8, 2019 at 7:48 PM Saku Ytti wrote:
> > Why do you think it would be expensive? It's cheaper than how ECMP is
> > done for L3 keys, because you just read the flow label and not
> > calculate any hash.
>
> The most
Mark Andrews wrote:
> Why should the rest of the world have to put up with their inability
> to purchase devices that work with RFC compliant data streams.
Because RFCs specifying IPv6 are broken.
That is, as PTB is generated against multicast, we should block
them. Then, not blocking PTB
On Fri, Mar 8, 2019 at 5:45 AM Brandon Martin
wrote:
> ICMP is nice in that it's totally protocol agnostic and doesn't require
> altering of packets in transit. It's a shame we can't reasonably rely
> on it being delivered.
>
Path MTU discovery is broken. It's the one place in TCP/IP where the
On Fri, Mar 8, 2019 at 7:07 PM Töma Gavrichenkov wrote:
> It's been a while since then, and maybe there was a mistake on our
> side (at least within a perfectly academic context I must assume that
> there was, as there was no peer review — we were not in academy after
> all!), but I'm still
On Fri, Mar 8, 2019 at 7:48 PM Saku Ytti wrote:
> Why do you think it would be expensive? It's cheaper than how ECMP is
> done for L3 keys, because you just read the flow label and not
> calculate any hash.
The most honest answer would be: I have no idea. That's just what I've
seen, rather
On Fri, Mar 8, 2019 at 5:44 PM Töma Gavrichenkov wrote:
> My point is that it might be hard to find an affordable device that
> implements ECMP with v6 flow labels without a considerable performance
> impact. I would personally happy to see what others have tested in
> that regard.
Why do you
On Fri, Mar 8, 2019 at 5:11 PM Saku Ytti wrote:
> Personally I'm surprised if ICMP volume is relevant based on our
> netflow data.
Legitimate ICMP traffic volume — oh, that's for sure.
But when it comes to attack volumes, it's a different story, and
current netflow measurements might be a bad
hey,
The Cloudflare blog
entry is 4 years old, if they had started actively pursuing proper fix
to the ECMP problem, the fix would be in production right about now.
You can find more recent overview at
https://blog.cloudflare.com/increasing-ipv6-mtu/
--
tarko
Hey Töma,
> NB: Cloudflare is basically busy filtering excessive amounts of spoofed ICMP
> packets containing whatever parameters and payload criminals could fit into,
> at virtually no cost for a customer. Your list might become somewhat short
> then.
I don't know what is the problem is
On 2019-03-08 14:45, Brandon Martin wrote:
> On 3/8/19 8:38 AM, Saku Ytti wrote:
>> Hey,
>>
>>> now for UDP, I don't know yet how does things like QUIC can be handled
>>> ...
>>
>> Unfortunately the magic answer you were hoping does not exist, what
>> they do is they just send smaller
On Tue, Mar 5, 2019, 7:27 AM Mark Andrews wrote:
> [..]
their inability to purchase
> devices that work with RFC compliant data streams.
>
To prove your point, you may want to provide a sample list of devices that
work that way, along with the benchmarks showing that those devices could
still
On 3/8/19 8:38 AM, Saku Ytti wrote:
Hey,
now for UDP, I don't know yet how does things like QUIC can be handled ...
Unfortunately the magic answer you were hoping does not exist, what
they do is they just send smaller packets.
What we almost seem to be moving toward in this
Hey,
> now for UDP, I don't know yet how does things like QUIC can be handled ...
Unfortunately the magic answer you were hoping does not exist, what
they do is they just send smaller packets.
--
++ytti
hello,
Tore Anderson, you're right, clamping MSS is very efficient and very
certainly solves most of the problems.
now for UDP, I don't know yet how does things like QUIC can be handled ...
regards,
--
Jean-Daniel Pauget http://rezopole.net/
* Jean-Daniel Pauget
> I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
> service
> of the concerned operator doesn't handle IPv6 yet.
>
> as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
> (rfc 4443)
> seem to be ignored or
> On 6 Mar 2019, at 1:36 pm, Fernando Gont wrote:
>
> On 5/3/19 03:26, Mark Andrews wrote:
>>
>>
>>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>>>
>>>
>>>
>>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>>
Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
On 5/3/19 03:26, Mark Andrews wrote:
>
>
>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>>
>>
>>
>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>
>>>
>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>>> they have installed broken ECMP devices. The simplest way to do that
On 27/2/19 07:01, Jean-Daniel Pauget wrote:
> hello,
>
> I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
> service
> of the concerned operator doesn't handle IPv6 yet.
>
> as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
> (rfc
On Tue, Mar 5, 2019 at 10:09 AM Bjørn Mork wrote:
> Stephen Satchell writes:
> > Did you submit a bug report?
>
> I believe this was fixed 5 years ago (in Linux v3.17):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73
>
>
Stephen Satchell writes:
> On 3/5/19 2:54 AM, Thomas Bellman wrote:
>> Out of curiosity, which operating systems put anything useful (for use
>> in ECMP) into the flow label of IPv6 packets? At the moment, I only
>> have access to CentOS 6 and CentOS 7 machines, and both of them set the
>> flow
On 3/5/19 2:54 AM, Thomas Bellman wrote:
> Out of curiosity, which operating systems put anything useful (for use
> in ECMP) into the flow label of IPv6 packets? At the moment, I only
> have access to CentOS 6 and CentOS 7 machines, and both of them set the
> flow label to zero for all traffic.
> Out of curiosity, which operating systems put anything useful (for use
> in ECMP) into the flow label of IPv6 packets? At the moment, I only
> have access to CentOS 6 and CentOS 7 machines, and both of them set the
> flow label to zero for all traffic.
FreeBSD 11.2-STABLE.
Steinar Haug,
On Tue, Mar 5, 2019 at 12:09 PM Joel Jaeggli wrote:
> Parsing the icmp payload was something we considered in rfc7690 but wasn’t
> one the approaches we pursued (we broadcasted the ptb to all hosts on the
> segment(s) behind the load balancers in our original implementation).
>
> It actually
On 2019-03-05 07:26 CET, Mark Andrews wrote:
> It does work as designed except when crap middleware is added. ECMP
> should be using the flow label with IPv6. It has the advantage that
> it works for non-0-offset fragments as well as 0-offset fragments and
> also works for transports other than
Sent from my iPhone
> On Mar 5, 2019, at 01:31, Saku Ytti wrote:
>
>> On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote:
>>
>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>> they have installed broken ECMP devices. The simplest way to do that
>
> Out of curiosity
On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote:
> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
> they have installed broken ECMP devices. The simplest way to do that
Out of curiosity does that imply you are aware of non-broken ECMP
devices, which are able to hash on
Sent from my iPhone
> On Mar 4, 2019, at 22:26, Mark Andrews wrote:
>
>
>
>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>>
>>
>>
>>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>>
>>>
>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>>> they have installed broken
On 5/Mar/19 08:26, Mark Andrews wrote:
> It does work as designed except when crap middleware is added. ECMP
> should be using the flow label with IPv6. It has the advantage that
> it works for non-0-offset fragments as well as 0-offset fragments and
> also works for transports other than TCP
> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>
>
>
> On 5/Mar/19 00:25, Mark Andrews wrote:
>
>>
>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>> they have installed broken ECMP devices. The simplest way to do that
>> is to set the interface MTUs to 1280 on all
On 5/Mar/19 00:25, Mark Andrews wrote:
>
> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
> they have installed broken ECMP devices. The simplest way to do that
> is to set the interface MTUs to 1280 on all the servers. Why should
> the rest of the world have to put up
> On 5 Mar 2019, at 6:06 am, Saku Ytti wrote:
>
> Hey Jean,
>
>>I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
>> service
>>of the concerned operator doesn't handle IPv6 yet.
>>
>>as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
Hey Jean,
> I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
> service
> of the concerned operator doesn't handle IPv6 yet.
>
> as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
> (rfc 4443)
> seem to be ignored or filtered at ~60%
hello,
I confess using IPv6 behind a 6in4 tunnel because the "Business-Class"
service
of the concerned operator doesn't handle IPv6 yet.
as such, I realised that, as far as I can figure, ICMPv6 packet "too-big"
(rfc 4443)
seem to be ignored or filtered at ~60% of
39 matches
Mail list logo
