dhcpcd-discuss

On Thursday 28 January 2016 22:24:08 Nick Williams wrote:
> I don’t imagine that a scenario where multiple interfaces are getting DHCP
> addresses is very common for users of VyOS, but it’s certainly possible and
> supported. So how do you tell dhcpcd which interface to prefer over others
> for setting default routes and DNS? What will dhcpcd do if you //don’t//
> tell it which to prefer?

Each interface has an index (assigned by the kernel), we use this as a base + 
200.
If it's a wireless interface we add another 100 so we generally prefer wired.
You can configure it explicity in dhcpcd.conf like so

# Most preferred
interface eth1
metric 1

# Least preferred
interface eth0
metric 999

> > Now, to allay your fears you can do this:
> > # start dhcpcd in master mode
> > dhcpcd -M
> > # edit the config to make a change to eth1
> > vim /etc/dhcpcd.conf
> > # notify dhcpcd of the change to eth1
> > dhcpcd -n eth1
> 
> Okay. This is very useful information. I have some follow-up scenario
> questions:
> 
> - Can you start `dhcpcd -M` with a configuration that basically says “don’t
> do anything with an interface unless it’s specifically mentioned in this
> config file?” In essence, VyOS doesn’t always know about all interfaces
> unless they are configured, and even for those it does know about, it would
> be a complication to the config system is it had to explicitly exclude
> interfaces from DHCP configuration whenever configured without DHCP. It
> would be much easier to only add DHCPCD configuration for those interfaces
> that want DHCP, and simply ignore the ones that don’t. Is that possible? (I
> think denyinterfaces really messed up my thought process on this. Makes it
> seem like you have to explicitly disable DHCP for any interface that
> doesn’t want it.)

Mostly yes

allowinterfaces eth0 eth1

So if eth2 and eth3 exist but aren't on that config line then dhcpcd will never 
ever touch them UNLESS told do as part of PD or on the command line or they 
have an address or route eth0 or eth1 needs.

> - If you notify dhcpcd of a change to an interface (`-n eth1`), it won’t
> bring all interfaces down and back up, right? It will only affect the
> interface that changed?

Correct
It won't even bring the interface down (unless you have the nopersistent 
option, but even then it removes config, dhcpcd won't touch the link itself).

> - If you notify dhcpcd of a change to an interface, and dhcpcd sees that,
> for example, the DHCPv4 configuration hasn’t changed (was and is on), but
> the DHCPv6 configuration did change (wasn’t on and is now), will dhcpcd
> bring down the entire interface and bring it back up? Or will it just make
> the v6 changes without affecting the still-valid v4 configuration?

It won't bring the config down, it will stay.
However, all protocols will rebind which means once the command is given there 
is a short window to get a positive response before dhcpcd begins fallbacks.

> > Now, to be truthful, the last step does work, it's just not very well
> > tested. For example, I don't recall if you can stop a protocol once it's
> > started.
> So, if I understand it correctly, `dhcpcd -M` with per-interface
> notifications //will// work, but it’s not as well tested, and may have some
> issues, so the more-safe option is to do one-dhcpcd-instance-per-interface?

Safe for what? I don't agree that te dhcpcd instance per interface is safer - 
see my earlier email for why.
I claim it works fine, but also that it's a very unused feature compared to 
others which are very well tested.
You should really perform your own due diligence on all features to integrate 
with.

> > Almost right.
> > sla_id 0 is reserved for when you're delegated a /64 and want to divvy out
> > a /64 - you can only do that without altering the prefix so obviously for
> > only one interface
> > 
> > ia_pd 2/::/60 eth1/1/64 eth2/2/64 eth3/3/64
> > 
> > Is fine.
> > But this is better
> > 
> > ia_pd 2 eth1 eth2 eth3
> > 
> > 
> > dhcpcd will default to incrementing the sla_id as needed (may not always
> > be
> > 1,2,3, depends on prefix and interface indexes for starters) and will
> > default to a 64 prefix unless bigger is needed. In this case it uses the
> > smallest prefix inside what we're delegating to.
> > 
> > The DHCPv6 protocol does not require you to request a specific prefix, or
> > length, but the first example I gave shows you how to request a blank
> > address (ie, not requested, but the config requires it) and a prefix
> > length. From memory, some Comcast customers who posted here said they did
> > not need to specify a /60 - some even got a /56
> 
> Beautiful. This means we can //let// them specify a prefix length if they
> really want to, but we can also omit it and useful defaults will prevail. I
> like it. Thanks!

:)
 
> Do I understand correctly that everything after `interface <name>` in the
> configuration file is configuration specific to that interface? So, for
> multiple interfaces, you’d do:
> 
> <global config options>
> interface eth0
> <eth0 config options>
> interface eth1
> <eth1 config options>

Exactly

> Can you have per-interface configuration files and import/combine them
> somehow, or point dhcpcd to a directory of them? That would make
> configuration much easier for us. What would that look like?

No.
That doesn't mean it can't be done.

But equally editing the config as is isn't hard either.
See here: http://roy.marples.name/projects/dhcpcd-ui/artifact/32d2b6dc9746cfb8

That is used by dhcpcd-gtk and dhcpcd-qt to configure each interface as needed.


> >> I noticed that the ip_pd documentation in the man page for dhcpcd.conf
> >> demonstrates also using `denyinterfaces eth2` in this case, but I'm not
> >> sure what that accomplishes here, and we seem to be using eth2
> >> essentially
> >> the same way as eth1 and eth3. I would love some clarification on this.
> > 
> > So don't deny it :)
> > denyinterfaces basically means dhcpcd will never use that interface
> > (unless a ia_pd actively touches it or instructed to from the
> > command-line)
> 
> See my comment about this above. This sure makes it sound like you have to
> intentionally turn off dhcp for interfaces that don’t want it.

Correct.

> >> As a further example, for the sake of context, this same dhcpcd config
> >> would be generated using the following router config:
> >> 
> >> # show interfaces ethernet eth0 dhcpv6-pd
> >> pd 1 {
> >> 
> >>    interface eth1 {
> >>    
> >>        service slaac
> >>    
> >>    }
> >>    interface eth2 {
> >>    
> >>        service slaac
> >>    
> >>    }
> >>    interface eth3 {
> >>    
> >>        service slaac
> >>    
> >>    }
> >>    prefix-length 60
> >> 
> >> }
> > 
> > Interesting.
> > We've not talked about slaac at all and I see it just now.
> > What does it mean in this context?
> 
> I need to think about this a bit more to be sure, but I don’t think `service
> slaac` is related to dhcpcd at all. It’s appropriate at that spot in the
> config, because it’s related to PD, but it’s actually a config telling the
> DHCP //server// to enable SLAAC on those interfaces.

DHCP server's don't care about SLAAC.
RA servers don't either.
SLAAC is strictly a client only thing.

Roy