dhcpcd-discuss

Hi Donald

On 04/03/2019 15:53, Donald Sharp wrote:
> All --
>
> Linux VRF's recently were introduced to the linux kernel:
>
> https://www.kernel.org/doc/Documentation/networking/vrf.txt
>
> Effectively vrf devices show up as an interface and interfaces that
> you want to exist within a particular vrf you mark the vrf device as
> it's master.  Then when packets come in on that interface the table
> associated with the vrf is used for lookup for packet forwarding.
>
> Currently dhcpcd treats all non-default linux table routes as
> something to be ignored in if_copyrt():
>
> rtm = (struct rtmsg *)NLMSG_DATA(nlm);
> if (rtm->rtm_table != RT_TABLE_MAIN)
>          return -1;
>
> Are there any plans to support this in dhcpcd?

So I read up on VRF and a lot of it comes from your company it seems.
I'm struggling to see where a DHCP client fits in as this is mainly at 
Layer 2, only using Layer 3 for DHCP renew. VRF is only Layer 3?

Anyway here's my understanding.
An interface is tagged with a VRF table - this equates to rtm_table in 
netlink messages. All routes for this interface should be placed into 
this table?
Is there an API (ideally kernel level) for discovering which VRF table 
an interface belongs to, or does this need to be configured in dhcpcd?
Is this set when the interface is annouced, or can be it set/changed 
later and does this send a netlink message to notify of this?
If it does sent a netlink message and the VRF table changes, is the 
expected behaviour just to flush dhcpcd routes from old table and 
re-insert into new, or is a rebind expected?

Or have I missed the boat on this?
If so, can you explain what's needed in dhcpcd for this?

I think that's all for now.

Roy