dhcpcd-discuss

Roy -

That is more than fair.  It's gonna have to be in my spare time though :(

donald

On Fri, Mar 8, 2019 at 8:24 AM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>
> 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
> >