All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Brunel <jjk@jjacky.com>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: netdev@vger.kernel.org
Subject: Re: Bug w/ (policy) routing
Date: Mon, 2 Jan 2017 18:05:48 +0100	[thread overview]
Message-ID: <20170102180548.1390a09c@jjacky.com> (raw)
In-Reply-To: <c59bcb99-39d1-3b47-7787-dd4d805eb4f6@cumulusnetworks.com>

On Mon, 2 Jan 2017 09:48:12 -0700
David Ahern <dsa@cumulusnetworks.com> wrote:

> 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:

Indeed, and that's a much better solution for me, since I bring lo up
anyways, I might as well do it first. Thank you.


> 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

      reply	other threads:[~2017-01-02 17:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-30 23:00 Bug w/ (policy) routing Olivier Brunel
2016-12-31 20:15 ` David Ahern
2017-01-01 19:52   ` Olivier Brunel
2017-01-02 16:48     ` David Ahern
2017-01-02 17:05       ` Olivier Brunel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170102180548.1390a09c@jjacky.com \
    --to=jjk@jjacky.com \
    --cc=dsa@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.