On 10/25/16 8:48 PM, Eric Dumazet wrote: > Maybe I do not understand how you plan to use this. > > Let say you want a filter to force a BIND_TO_DEVICE xxx because a task > runs in a cgroup yyy > > Then a program doing a socket() + connect (127.0.0.1) will fail ?
maybe. VRF devices can have 127.0.0.1 address in which case the connect would succeed. ntpq uses 127.0.0.1 to talk to ntpd for example. If ntpd is bound to a Management VRF, then you need this context for ntpq to talk to it. > > I do not see how a BPF filter at socket() time can be selective. Here's my use case - and this is what we are doing today with the l3mdev cgroup (a patch which has not been accepted upstream): 1. create VRF device 2. create cgroup and configure it in this case it means load the bpf program that sets the sk_bound_dev_if to the vrf device that was just created 3. Add shell to cgroup For Management VRF this can be done automatically at login so a user does not need to take any action. At this point any command run in the shell runs in the VRF context (PS1 for bash can show the VRF to keep you from going crazy on why a connect fails :-)) so any ipv4/ipv6 sockets have that VRF scope. For example, if the VRF is a management VRF, sockets opened by apt-get are automatically bound to the VRF at create time, so requests go out the eth0 (management) interface. In a similar fashion, using a cgroup and assigning tasks to it allows automated launch of systemd services with instances running in a VRF context - one dhcrelay in vrf red, one in vrf blue with both using a parameterized instance file.
