HI David,
Thanks a lot for your response. It clarifies few of my questions.
Please see inline for with tag MOHAN> for my response.
Thanks
Krishna Mohan.
-----Original Message-----
From: David Ahern [mailto:[email protected]]
Sent: Monday, April 25, 2016 5:01 AM
To: Elluru, Krishna Mohan <[email protected]>; [email protected]
Subject: Re: VRF_DEVICE integration plan
On 4/23/16 10:07 PM, Elluru, Krishna Mohan wrote:
> HI Netdev team,
>
> Greetings. We have been monitoring the vrf device approach for l3
> isolation from cumulus networks and we are currently interested in validating
> it. We have following questions on them and hoping to get answers from
> you/concerned team.
>
> 1. As per the linux documentation, there are known limits on if_index lookup,
> as the incoming if_index is changed to vrf_device index and thus an
> application receiving this packet will perceive this as a vrf_device packet,
> than right if_index. I saw you mentioned about a special flag to identify the
> origin, but didn't see the same in the latest linux 4.4.2 version code. Is
> there a patch expected for it?
you are referring to IP{6}_PKTINFO? I have patches from our 4.1 kernel tree
that I have rebased to top of tree. I hope to send those out in the next few
weeks.
MOHAN> Yes. Sure. Thanks.
>
> 2. What are the future additions planned for this approach? Are there any
> ipv4 and ipv6 known bugs with vrf_device model?
We have about 20 patches in our tree that I have not sent upstream yet.
Those patches fix PKTINFO, allow local traffic (e.g, ping in a VRF to a
local address in a VRF), allow IPv6 multicast and linklocal traffic, and
the cgroup implementation which has been sent as an RFC.
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?
>
> 3. It has been said in the documentation that, with addition of cgroup
> functionality for vrf device, with net_admin capabilities, we should be able
> to add an interface to vrf_device, currently it is not so. Any timelines on
> these?
I don't understand that question. The current implementation allows
adding interfaces (netdev's) to a VRF. The cgroup allows running a
process in a VRF context such that AF_INET{6} sockets are automatically
bound to the VRF device.
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?
>
> 4. Currently the changes are available and portable from 4.3.x onwards. Is
> there a plan to port them to previous kernel versions?
no. Anyone wanting to use the vrf patches on other kernel versions will
need to port them.
MOHAN> Sure.
>
> 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
>
> 6. With "VRF Device" in place, please confirm if there are any plans to add
> VRF support for applications like
>
> 1. Ping
no need. ping{6} -I <vrf device> ...
> 2. Traceroute
no need. traceroute{6} -i <vrf device> ...
> 3. DNS-Client [glibc]
>
> In case of DNS-Client, most of the name resolution APIs will have to
> consider the VRF to do the lookup in and the way the domain-name/name-server
> configuration is stored.
I have looked into it but no patches worth distributing at the moment.
MOHAN> Okay, thanks for the inputs.
