Re: [BUG][iproute2][5.0] ip route show table default: "Error: ipv4: FIB table does not exist."

From: David Ahern <dsahern@gmail.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: emersonbernier@tutanota.com, Netdev <netdev@vger.kernel.org>,
	Stephen <stephen@networkplumber.org>,
	Kuznet <kuznet@ms2.inr.ac.ru>, Jason <jason@zx2c4.com>,
	Davem <davem@davemloft.net>
Subject: Re: [BUG][iproute2][5.0] ip route show table default: "Error: ipv4: FIB table does not exist."
Date: Sun, 24 Mar 2019 16:09:16 -0600	[thread overview]
Message-ID: <26689b18-e0f1-c490-7802-4256f12aa5e2@gmail.com> (raw)
In-Reply-To: <20190324183618.GB26076@unicorn.suse.cz>

On 3/24/19 12:36 PM, Michal Kubecek wrote:
> On Sun, Mar 24, 2019 at 07:29:08PM +0100, Michal Kubecek wrote:
>> On Sun, Mar 24, 2019 at 11:20:33AM -0600, David Ahern wrote:
>>> On 3/24/19 11:02 AM, emersonbernier@tutanota.com wrote:
>>>> Ok but previous versions of iproute2 didn't treat this as error and didn't exited with non-zero status. Is non existing default route a system error which needs fixing?
>>>
>>> The kernel is returning that error, not iproute2.
>>>
>>> It is the default *table*, not a default route.
>>
>> Something did change on iproute2 side between 4.20 and 5.0, though:
>>
>> lion:~ # rpm -q iproute2
>> iproute2-4.20-0.x86_64
>> lion:~ # ip route show table default ; echo $?
>> 0
>> lion:~ # ip route show table 123 ; echo $?
>> 0
>> ...
>> lion:~ # rpm -q iproute2
>> iproute2-5.0.0-0.x86_64
>> lion:~ # ip route show table default ; echo $?
>> Error: ipv4: FIB table does not exist.
>> Dump terminated
>> 2
>> lion:~ # ip route show table 123 ; echo $?
>> Error: ipv4: FIB table does not exist.
>> Dump terminated
>> 2
>>
>> All I did was updating iproute2 package, the same kernel was running for
>> both (I tried 5.0.3 and 5.1-rc1).
> 
> Commit c7e6371bc4af ("ip route: Add protocol, table id and device to
> dump request") seems to be an obvious candidate. Before it, no matching
> rules in the dump used to be presented as an empty table but now ip gets
> a kernel error which it displays to the user.
> 

It's the commit that enables strict checking. Kernel side has been
changed to better inform the user of what happens on a request when
strict checking is enabled. iproute2 has been updated to use this.

Essentially, ip asks for a dump of table 253. In the past there is no
data, so nothing to return. The strict checking tells you explicitly
"that table does not exist" versus the old method where nothing is
returned and the user has to guess "the table exists but is empty or
there is a bug dumping the table?"

Given the legacy of table 253/default, iproute2 can easily catch this
error and just do nothing for backwards compatibility.