[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACP96tTFX7nyGz6uARYxemvE7-WDxvX7Wj+Jf95PC0Advy7ynw@mail.gmail.com>
Date: Mon, 12 Sep 2016 22:03:55 -0400
From: Sowmini Varadhan <sowmini05@...il.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: Andreas Hübner <andreas@....de>,
netdev <netdev@...r.kernel.org>,
"d. caratti" <davide.caratti@...il.com>,
Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: icmpv6: issue with routing table entries from link local addresses
On Mon, Sep 12, 2016 at 1:26 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hello,
>
> On 12.09.2016 16:27, Andreas Hübner wrote:
>>
>> I have the following setup:
>> - 2 directly connected hosts (A+B), both have only link local addresses
>> configured (interface on both hosts is eth0)
:
>> fe80::/64 dev eth1 proto kernel metric 256
>> fe80::/64 dev eth0 proto kernel metric 256
:
>> The issue I currently have is, that the echo reply that host B should
>> generate is never sent back to host A. If I change the order of the
>> routing table entries on host B, everything works fine.
>> (host A is connected on eth0)
:
> This shouldn't be the case. We certainly carry over the ifindex of the
> received packet into the routing lookup of the outgoing packet, thus the
> appropriate rule, with outgoing ifindex should be selected.
Like Hannes, I too would first check "is B sending out the echo-resp? on
which interface?".
But a couple of unexpected things I noticed in linux: the link-local
prefix should have a prefixlen of /10 according to
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
but "ip -6 route show" lists this as a /64..
moreover, even though I cannot use "ip [-6] route add.." to add the
same prefix multiple times (with different nexthop and/or interface)
unless I explicitly mark them as ECMP with /sbin/ip, it seems like you
can create the same onlink prefix on multiple interfaces, but the
kernel will not treat this as an ECMP group (and sometimes this
can produce inconsistent results depending on the order of
route addition, e.g., for ipv4 rp_filter checks). I dont know if some
variant of this (latter observation) may be the reason for the behavior
that Andreas reports.
--Sowmini
Powered by blists - more mailing lists