dhcpcd-discuss

Roy -

This is the type of scenario that comes to mind immediately as to why
having dhcpcd be vrf aware would be good:
https://www.cisco.com/c/dam/en/us/td/i/100001-200000/120001-130000/121001-122000/121983.ps/_jcr_content/renditions/121983.jpg

Typically clients are running X copies of dhcpcd where X is the number of vrf's.

VRF's are signaled as part of the link data from the linux kernel,
specifically IFLA_LINKINFO and IFLA_INFO_SLAVE_KIND

https://github.com/FRRouting/frr/blob/master/zebra/if_netlink.c#L636

Effectively when you read in link state if an interface is in a vrf,
it is signaled via the above.  If an interface is moved from vrf to
vrf we get a callback that the link has changed and the code will need
to move the interface around per vrf.  When a vrf is deleted well get
callbacks saying the vrf device is deleted and callbacks that all
interfaces that it belonged to are moved to the default vrf.  Table
id's cannot change for the life of the vrf device once assigned.

donald

On Mon, Mar 4, 2019 at 4:53 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>
> 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