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
prev parent 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$(echo .)com \
--cc=anoop.g@hpe$(echo .)com \
--cc=elluru.kri.mohan@hpe$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shantha.kumara@hpe$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox