lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 2 May 2016 11:43:46 -0600 From: David Ahern <dsa@...ulusnetworks.com> To: "Elluru, Krishna Mohan" <elluru.kri.mohan@....com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Cc: "Kumara, Shantha (HP Networking)" <shantha.kumara@....com>, "Govindan Nair, Anoop" <anoop.g@....com> Subject: Re: VRF_DEVICE integration plan 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
Powered by blists - more mailing lists