All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsa@cumulusnetworks.com>
To: "Elluru, Krishna Mohan" <elluru.kri.mohan@hpe.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "Kumara, Shantha (HP Networking)" <shantha.kumara@hpe.com>,
	"Govindan Nair, Anoop" <anoop.g@hpe.com>
Subject: Re: VRF_DEVICE integration plan
Date: Mon, 2 May 2016 11:43:46 -0600	[thread overview]
Message-ID: <572791D2.9050701@cumulusnetworks.com> (raw)
In-Reply-To: <CS1PR84MB0072AC62E9EBCC5A42E33952CA650@CS1PR84MB0072.NAMPRD84.PROD.OUTLOOK.COM>

On 4/28/16 11:16 AM, Elluru, Krishna Mohan wrote:
>
> I posted a few bug fix patches a week or two ago. Not sure what the
> status is with respect to 4.3 - 4.5 trees.
>
> MOHAN> Sure. Are those patches sent over netdev mailer list?

yes. All patches for VRF - kernel and iproute2 - are sent to netdev.


> MOHAN> sorry for not being clear. My ask was, to create a namespace we need cap_admin privileges currently, but your earlier mails suggested that we should be able to configure/create vrf device with net_admin capabilities. Is this support present /expected to be added soon?

VRF is implemented using a netdevice. As such the ability to create one 
requires the same permissions as creating any other netdevice 
(CAP_NET_ADMIN).


>> 5. Is there a possibility of enabling secondary level lookup, to give a leak functionality to parent route table from device local route table? I tested with veth pair, configured one as default gateway, it is possible to forward traffic b/w the interfaces, looking for cleaner method.
>
> Are you referring to inter-vrf routing? See slide 27
> http://www.netdevconf.org/1.1/proceedings/slides/ahern-vrf-tutorial.pdf
> Full lookup in VRF table
> ▪ ip route add table vrf-red 1.1.1.0/24 dev vrf-green
> MOHAN> In slide 27 above shows inter vrf routing, requirement is to use current namespace global route table if the ip lookup fails in vrf-device routing table.
> Reference: https://www.juniper.net/techpubs/en_US/junose16.1/topics/task/configuration/mbgp-secondary-routing-table-search.html

One solution is to create a VRF device that is associated with the main 
table and then use an inter-vrf route to jump to the main table.

VRF tables do need a default route (e.g., unreachable with high metric 
value) else the FIB lookups will proceed to the next table which is most 
likely not what you want.


David

      reply	other threads:[~2016-05-02 17:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-24  4:07 VRF_DEVICE integration plan Elluru, Krishna Mohan
2016-04-24 23:30 ` David Ahern
2016-04-28 17:16   ` Elluru, Krishna Mohan
2016-05-02 17:43     ` David Ahern [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=572791D2.9050701@cumulusnetworks.com \
    --to=dsa@cumulusnetworks.com \
    --cc=anoop.g@hpe.com \
    --cc=elluru.kri.mohan@hpe.com \
    --cc=netdev@vger.kernel.org \
    --cc=shantha.kumara@hpe.com \
    /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.