Hello David,
A quick correction; The issue is not solved, it was a mistake in my
testing. The issue is still there.
Kfir
On Tue, Sep 1, 2020 at 1:40 PM mastertheknife wrote:
>
> Hello David.
>
> I was able to solve it while troubleshooting some fragmentation issue.
> The VTI
exist per nexthop entry.
Line 678:
"if (fnhe) {"
Should probably be:
"if (fnhe && fnhe->fnhe_daddr == daddr) {"
Thank you for your efforts,
Kfir Itzhak
On Fri, Aug 14, 2020 at 10:08 AM mastertheknife
wrote:
>
> Hello David,
>
> It's on a production sy
PSECs with VTi interfaces.
Everything is kernel 5.4.44 LTS
I wish i could fully reproduce all of it in a script, but i am not
sure how to create such hops that return this ICMP
Thank you,
Kfir
On Wed, Aug 12, 2020 at 10:21 PM David Ahern wrote:
>
> On 8/12/20 6:37 AM, mastertheknife wrote
avid Ahern wrote:
>
> On 8/3/20 12:39 PM, mastertheknife wrote:
> > In summary: It seems that it doesn't matter who is the nexthop. If the
> > ICMP response isn't from the nexthop, it'll be rejected.
> > About why i couldn't reproduce this outside LXC
exthop. If the
ICMP response isn't from the nexthop, it'll be rejected.
About why i couldn't reproduce this outside LXC, i don't know yet but
i will keep trying to figure this out.
Let me know if you need me to test this.
Thank you,
Kfir Itzhak
On Mon, Aug 3, 2020 at 6:38 PM Dav
,
Kfir
On Mon, Aug 3, 2020 at 4:32 PM David Ahern wrote:
>
> On 8/3/20 5:14 AM, mastertheknife wrote:
> > What seems to be happening, is that when multipath routing is used
> > inside LXC (or any network namespace), the kernel doesn't generate a
> > routing exception
Hi,
I have observed that PMTUD (Path MTU discovery) is broken using
multipath routing inside a network namespace. This breaks TCP, because
it keeps trying to send oversized packets.
Observed on kernel 5.4.44, other kernels weren't tested. However i
went through net/ipv4/route.c and haven't spotted
