Page MenuHomeVyOS Platform

DHCP Relay upstream and downstream interfaces
In progress, NormalPublicENHANCEMENT

Description

This is based on the T1276

Currently, the dhcp-relay service requires to specify both upstream and downstream interfaces to make the service working. There is no distinction for them in VyOS config syntax and in the isc-dhcp-relay config file.
Additionally, the current config syntax is not understandable for many users, especially for those who are used to Cisco or HP approach (ip helper set per L3 interface). They often ask why do they need to add DHCP server facing interfaces into the relay config.
Another drawback is that the current config makes the relay to generate an extra and needless DHCP REQUEST packet with a wrong address set in the giaddr field (details in T1276).

Current syntax and config file:

show service 
 dhcp-relay {
     interface eth0
     interface eth1
     relay-options {
         relay-agents-packets discard
     }
     server 172.16.0.254
 }
# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="eth0 eth1"

# Additional options that are passed to the DHCP relay daemon?
OPTIONS="-4 -a -m discard"

Proposed change:

show service 
 dhcp-relay {
     upstream-interface eth0
     downstream-interface eth1
     relay-options {
         relay-agents-packets discard
     }
     server 172.16.0.254
 }
# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES=""

# Additional options that are passed to the DHCP relay daemon?
OPTIONS="-4 -a -m discard -id eth0 -iu eth1"

IMPORTANT NOTE: the isc-dhcp-relay allows to differentiate between downstream and upstream interfaces since v4.3.5. Therefor, this change could be easily introduce into VyOS 1.3. For v1.2, the isc-dhcp-relay package upgrade would be required and I'm not sure if that is possible.

Details

Difficulty level
Unknown (require assessment)
Version
vyos-1.3 vyos-1.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)
Issue type
Improvement (missing useful functionality)

Event Timeline

Unknown Object (User) triaged this task as Normal priority.Apr 30 2020, 7:15 PM
Unknown Object (User) created this task.
erkin set Issue type to Improvement (missing useful functionality).Aug 30 2021, 6:27 AM
erkin removed a subscriber: Active contributors.
n.fort changed Version from - to vyos-1.3 vyos-1.4.

Currently thinking on how to implement this.
One option could be:

######### Config commands
set service dhcp-relay interface 'eth3'
set service dhcp-relay relay-options relay-agents-packets 'discard'
set service dhcp-relay server '203.0.113.2'

######## ->Content of /run/dhcp-relay/dhcrelay.conf
[email protected]# cat  /run/dhcp-relay/dhcrelay.conf
### Autogenerated by dhcp_relay.py ###

OPTIONS="-c 10 -a -m discard -A 576 -id eth3 -iu eth0 203.0.113.2"

Where:

  • -id eth3 --> Produced by command set service dhcp-relay interface 'eth3'
  • -iu eth0 --> Obtained automatically from routing table: interface from where server IP address is reachable

With this setup, it would only be necessary to specify downstream interface.
Limitations I see on this:

  • how to hand migration script. In example provided cli didn't change, but maybe specifying set service dhcp-relay interface downstream eth3, will requiere migration script, and currently see no options on how to handle this.
  • Configuration based on routing table: if route changes? If route to server doesn't exist?

Would it be an option to instead just add new listen-interface and upstream-interface statements, same as for dhcp-relay6? Then keep interface completely unchanged to avoid breaking weird usages, but add some deprecation notice to the CLI.

Also discussed this configuration:

set service dhcp-relay <tag> interface eth0 upstream
set service dhcp-relay <tag> interface eth1 downstream
set service dhcp-relay <tag> server <x.x.x.x>
set service dhcp-relay <tag> relay-options hop-count 1
set service dhcp-relay <tag> relay-options upsteam-port 547

+1 for @Viacheslav proposal.

But how we should handle migration from old config to new syntax? How we identify in configured scenarios, which interface is upstream and which one is downstream? I guess this is the main limitation and reason why this is not implemented yet.

n.fort changed the task status from Open to In progress.Oct 18 2022, 12:00 PM
n.fort claimed this task.