bind-to-interface option

[David Ahern]

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