[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c59bcb99-39d1-3b47-7787-dd4d805eb4f6@cumulusnetworks.com>
Date: Mon, 2 Jan 2017 09:48:12 -0700
From: David Ahern <dsa@...ulusnetworks.com>
To: Olivier Brunel <jjk@...cky.com>
Cc: netdev@...r.kernel.org, Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: Bug w/ (policy) routing
On 1/1/17 12:52 PM, Olivier Brunel wrote:
> Indeed, if I first delete the rule for lookup local and recreate it
> w/ higher prio than my "lookup 50", then no more issue.
After the unshare or when creating a new network namespace, bringing the lo device up will create the local table and the rest of the commands will work properly. ie., instead of moving the local rule you can run:
unshare -n bash
ip li set lo up
ip rule add table 50 prio 50
ip link add test type veth peer name test2
...
-----
Alex:
The order of commands is influencing whether the unmerge succeeds or not which is wrong. I took a quick look and I don't see a simple solution to this. Effectively:
Adding a rule before bringing up any interface does not unmerge the tables:
$ unshare -n bash
$ ip rule add table 50 prio 50
$ ip li set lo up
In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.
Where the reverse order works:
$ unshare -n bash
$ ip li set lo up
$ ip rule add table 50 prio 50
David
Powered by blists - more mailing lists