On 11/23/15 4:50 PM, Damien Miller wrote:> On Sun, 22 Nov 2015, David Ahern wrote: > >> Hi: >> >> The openssh suite of commands have an option to specify address (e.g, >> ListenAddress for sshd) but I do not see support for bind-to-interface. >> >> The motivating use case for me is using openssh commands (sshd, ssh, scp, >> sftp) with the recent VRF capability added to the Linux kernel. The VRF design >> relies on the bind-to-interface option to select the correct routing tables. >> Before I started working on patches I wanted to get a sense of whether it >> would be accepted. > > What's wrong with the existing BindAddress option? >For my use case the problem is that it is an address, not a device. The VRF implementation with Linux expects tasks to use the SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use of a route table associated with the VRF domain which can encapsulate one or more network interfaces. Addresses are local to a VRF domain (e.g., 2 interfaces in 2 different VRFs can have the same IP address). i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to device option.
On 23 Nov 2015, at 23:59, David Ahern <dsa at cumulusnetworks.com> wrote:>> What's wrong with the existing BindAddress option? >> > > For my use case the problem is that it is an address, not a device. > > The VRF implementation with Linux expects tasks to use the SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use of a route table associated with the VRF domain which can encapsulate one or more network interfaces. Addresses are local to a VRF domain (e.g., 2 interfaces in 2 different VRFs can have the same IP address). > > i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to device option.Just to add a little more colour to this, I believe the reason that SO_BINDTODEVICE is necessary rather than binding to the address is that in a VRF environment the same address may be present on multiple interfaces. Therefore, address cannot be used in order to select the VRF. However, the VRF can be uniquely determined from the interface. -- Alex Bligh
On 11/23/15 11:52 PM, Alex Bligh wrote:> > On 23 Nov 2015, at 23:59, David Ahern <dsa at cumulusnetworks.com> wrote: > >>> What's wrong with the existing BindAddress option? >>> >> >> For my use case the problem is that it is an address, not a device. >> >> The VRF implementation with Linux expects tasks to use the SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use of a route table associated with the VRF domain which can encapsulate one or more network interfaces. Addresses are local to a VRF domain (e.g., 2 interfaces in 2 different VRFs can have the same IP address). >> >> i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to device option. > > Just to add a little more colour to this, I believe the reason that SO_BINDTODEVICE is necessary rather than binding to the address is that in a VRF environment the same address may be present on multiple interfaces. Therefore, address cannot be used in order to select the VRF. However, the VRF can be uniquely determined from the interface.Yes, but routing is broken as well. ie., you can bind to the address, but the connection will not work because the lookups are not directed to the proper table without the bind-to-device set. For example +------+ | task | +------+ +---------+ +---------+ | route | | vrf | ==> | table N | +---------+ +---------+ / | \ / | \ +------+ +------+ +------+ | dev1 | | dev2 | | dev3 | +------+ +------+ +------+ a.b.c.d e.f.g.h j.k.l.m If some task bound to the one of the addresses without binding to the VRF device the connection will not work -- the route lookups go to the main table, not the table associated with the VRF. So, it is both addresses possibly being non-unique across VRFs but also the route lookups needed to make the connection. David