dhcpcd-discuss

I'm still not sure I fully understand all this and have no time to 
explore this futher. I also lack the time to setup a VRF environment for 
a few weeks.

If you are willing to provide a patch for dhcpcd to enable this, I will 
surely review it.

Roy

On 04/03/2019 23:52, Donald Sharp wrote:
> 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