Hello Eric, On Mon, 2015-07-27 at 15:33 -0500, Eric W. Biederman wrote: > David Ahern <d...@cumulusnetworks.com> writes: > > > Allow tasks to have a default device index for binding sockets. If > > set > > the value is passed to all AF_INET/AF_INET6 sockets when they are > > created. > > > > The task setting is passed parent to child on fork, but can be set > > or > > changed after task creation using prctl (if task has CAP_NET_ADMIN > > permissions). The setting for a socket can be retrieved using > > prctl(). > > This option allows an administrator to restrict a task to only > > send/receive > > packets through the specified device. In the case of VRF devices > > this > > option restricts tasks to a specific VRF. > > > > Correlation of the device index to a specific VRF, ie., > > ifindex --> VRF device --> VRF id > > is left to userspace. > > Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> > > Because it is broken by design. Your routing device is only safe for > programs that know it's limitations it is not appropriate for general > applications. > > Since you don't even seen to know it's limitations I think this is a > bad path to walk down.
Can you please elaborate about the broken by design? Different operating systems are already using this approach with good success. I read your other mail regarding isolation of different VRFs and I agree that all code which persists state depending solely on the IP address is affected by this and this must be dealt with and fixed (actually, there aren't too many). But I wouldn't call that broken by design. This stuff will get fixed like e.g. cross-talk between fragmentation queues, icmp rate limiters etc, which could already happen in the past. What is your opinion on the fundamental approach only from a user perspective? Do you think that is broken, too? Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
