Bug 49837 - Improve UMC policy vs. DHCP inheritance usability
Improve UMC policy vs. DHCP inheritance usability
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: DHCP
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 5.x
Assigned To: UCS maintainers
UCS maintainers
:
Depends on: 50704
Blocks: 50007
  Show dependency treegraph
 
Reported: 2019-07-11 16:57 CEST by Christian Völker
Modified: 2023-10-05 13:40 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.137
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019062921000441, 2020072621000424, 2023031321000352
Bug group (optional):
Max CVSS v3 score:


Attachments
Testcase (3.61 KB, text/plain)
2019-07-22 17:33 CEST, Philipp Hahn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Völker univentionstaff 2019-07-11 16:57:30 CEST
Situation:
* multiple networks separated by a router
* UCS acts as DHCP server with the help of DHCP-Relays from the networks
* Having a single domain all networks are configured as subnets
* the domain object hold the DHCP-Server
* within the domain object all computers are stored
* Policy is set to allow unknown clients
* Every subnet has it's policy where the gateway is configured

Unknown clients get an ip address from within the network they are attached to and receive the proper gateway so they are fully functional.

1. Add a client through computer/computers (ie an Ip managed client)
2. assign a MAC and a IP-adress pair (IP from range of the subnet where the client will be connected to)
3. boot client

Now the known client is stored as computer object directly in the domain branch. It does not inherit the policies from the subnet where it is connected to. Instead it gets the gateway policy from the domain object which matches only a single network.

For most of the clients you need to add the correct policy manually which is not really the purpose of using policies. Because this way we do not need policies as we have to edit the object manually anyways...


Expected behaviour:
By assigning a client to a network it should inherit the policies from the matching subnet object  so no manual edit is needed.
Comment 1 Philipp Hahn univentionstaff 2019-07-22 17:33:19 CEST
Created attachment 10129 [details]
Testcase
Comment 2 Philipp Hahn univentionstaff 2019-07-22 18:04:58 CEST
I just tested it again and it works as expected:
- make sure no (routing) policy get assigned to the DHCP service (or the container containing the dhcp/hosts entries)
- create a dhcp/subnet for each VLAN
- create and attach a specific dhcp/routing policy to each such dhcp/subnet

The structure should then look like this:

- $base -> *
  ...
  - cn=policies
    - cn=routing-vlan1
    - cn=routing-vlan2
      ...
  - cn=dhcp -> *
    - cn=my-service -> *
      - cn=vlan1 -> ref:routing-vlan1
      - cn=vlan2 -> ref:routing-vlan2
        ...
      - cn=host1
      - cn=host2
        ...
*: no dhcp/routing policies here


(In reply to Christian Völker from comment #0)
> Now the known client is stored as computer object directly in the domain
> branch. It does not inherit the policies from the subnet where it is
> connected to. Instead it gets the gateway policy from the domain object
> which matches only a single network.

DO NOT attach a policy to the LDAP-base, the DHCP service or and intermediate container in between!
This is documented in <https://docs.software-univention.de/manual-4.4.html#networks::dhcp::policies>!
Comment 3 Christian Völker univentionstaff 2019-07-29 13:07:09 CEST
It is not an issue of a centralized "default"-policy!

Structure with VLANs as described. Additionally, networks configured in "Domain" part of UMC.

Creating a new computer and assigning to one of these networks.
The object is placed directly under the DHCP service and not in the correct subnet.

If a policy is assigned to the DHCP service (despite documentation) the computer gets the routing from DHCP-service.

If NO policy is assigned it does NOT get any gateway!


Expected behaviour:
When a computer is created and assigned to a network and an IP address is given as fixed address with MAC the computer should inherit the correct gateway! 


NOTE: We are not talking about unknown clients- they will start in the network and get the proper gateway assigned.
But known clients get the wrong gateway. Every time!
Comment 4 Philipp Hahn univentionstaff 2019-07-31 09:21:33 CEST
(In reply to Christian Völker from comment #3)
> Structure with VLANs as described. Additionally, networks configured in
> "Domain" part of UMC.

I assume you a referencing "UDM networks/network" here.

> Creating a new computer and assigning to one of these networks.
> The object is placed directly under the DHCP service and not in the correct
> subnet.

This is by design: "UDM dhcp/host" objects MUST be placed below "UDM dhcp/service" and NOWHERE ELSE! They are global (per service) by design.
Even if you put them in a "isc-dhcpd subnet" statement in the traditional "/etc/dhcp/dhcpd.conf" file, they are still global. Putting them in a subnet does NOT restrict this host declaration to that subnet!

This is not something Univention invented, this is how isc-dhcp works by design!

> If a policy is assigned to the DHCP service (despite documentation) the
> computer gets the routing from DHCP-service.

Yes, this is why we tell you not to do that: If you have multiple subnets with different IP ranges and as such different default gateways, you MUST assign an individual "UDM policy/dhcp_routing" policy to the subnets and NOT the service!

> If NO policy is assigned it does NOT get any gateway!

Assign individual routing policies to each subnet!

> Expected behavior:
> When a computer is created and assigned to a network and an IP address is
> given as fixed address with MAC the computer should inherit the correct
> gateway! 

It does if you assign the correct policy to each subnet!

> NOTE: We are not talking about unknown clients- they will start in the
> network and get the proper gateway assigned.
> But known clients get the wrong gateway. Every time!

Do not assign a policy to the "dhcp/service" or to any container above!

See Bug #31650 comment 1 for more details.

Internally isc-dhcpd works like this:
- the DHCP server receives a "DHCP DISCOVER" Ethernet packet on one of its interfaces (or via a DHCP replay server). Record that information
- lookup any "host" declaration by MAC address and get "fixed-addresses".
- lookup the "subnets" to which those addresses belong
- pick that subnet, which matches the interface on the host, on which the DISCOVER was received
- aggregate the options from the "host", "pool", "subnet", "service" configurations and send back "DHCP OFFER".

A typical "dhcpd.conf" looks like this:
  option ... # service level
  subnet 1.0.0.0 netmask 255.0.0.0 {  # eth1
    option ... # subnet level
    pool {
      option ... # pool level
    }
    ...
  }
  subnet 2.0.0.0 netmask 255.0.0.0 {  # eth2
    ...
  }
  shared-network eth3 {  # eth3
    subnet 10.0.0.0 netmask 255.255.255.0 { ... }
    ...
  }
  host ... {
    hardware ethernet 0:00:11:22:33:44:55;
    fixed-address 1.0.0.1, 2.0.0.1;
    option ... # host level
  }

This matches our UDM modules 1:1:
  dhcp/service
    dhcp/subnet respective dhcp/shared + dhcp/sharedsubnet
      dhcp/pool
    dhcp/host

Again: isc-dhcp has a BUILT-IN policy mechanism: <man:dhcpd.conf(5)>
> When  a  client is to be booted, its boot parameters are determined by consulting that client's host declaration (if any),
> and then consulting any class declarations matching the client, followed by the pool, subnet and  shared-network  declara‐
> tions  for  the IP address assigned to the client.   Each of these declarations itself appears within a lexical scope, and
> all declarations at less specific lexical scopes are also consulted for client option  declarations.    Scopes  are  never
> considered twice, and if parameters are declared in more than one scope, the parameter declared in the most specific scope
> is the one that is used.

If you assign any UDM policy to the "UDM dhcp/service" object, that policy gets applied to ALL levels below, so ALSO to any "dhcp/host", "dhcp/subnet", "dhcp/pool", ... object. This leads to a "dhcpd.conf" like this:
  option FROM_SERVICE
  subnet ... {
    option FROM_SERVICE
    pool {
      option FROM_SERVICE
   }
  host .. {
    option FROM_SERVICE
  }

Quoting the important sentence from above again:
> its […] parameters are determined [from the] host declaration […]
> the parameter declared in the most specific scope is the one that is used.

So if you apply a 2nd policy of the same type to the subnet or pool, THEY ARE IGNORED!
Again: DO NOT assign policies to the dhcp/service if you have MULTIPLE subnets and want to use DIFFERENT policies per subnet!

This is how isc-dhcp works and is designed to work.
I verified that is does for UCS-4.4 product tests and with the attached mini-test-script.
VLANs are not relevant for this issue as they must be handled outside DHCP (→RADIUS).
As such: RESOLVED-WORKSFORME
Comment 5 Christian Völker univentionstaff 2020-07-27 11:45:48 CEST
Another customer affected by this misunderstanding.

As part of bug #50704 we should improve the frontend about thee policies.

Customer using VLANs and after some support from me he configured it all in the way it should be:
* created a network
* created the reverse-DNS zone
* created a subnet in dhcp service
* configured this subnet with the policy for routing

But he had configured a (expected default) policy in the dhcp object itself. So the policy for the subnet never came into play.

Removing the policy from global dhcp service allowed the clients to get the proper gateway.
Comment 6 Ingo Steuwer univentionstaff 2020-07-27 12:01:18 CEST
My understand here is: the functionality is available, but the configuration is misleading and complex. So I change this entry to be aa feature request to improve the situation.
Comment 7 Ingo Steuwer univentionstaff 2021-04-28 10:15:43 CEST
to check if we can improve with UCS 5.1