Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reduce number of DHCP responder flows for LSPs #224

Closed
wants to merge 1 commit into from

Conversation

JacobTanenbaum
Copy link
Contributor

currently for every LSP two DHCP responder flows are created. These two flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == "0e4b7821-b5ae-4bff-9424-d7245c679150" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == "0e4b7821-b5ae-4bff-9424-d7245c679150" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0} && ip4.dst == {1.65.5.1, 255.255.255.255})

OVN may now respond to illegal DHCP packets like src=0.0.0.0/dst=1.65.5.1 but we have COPP for this and we should be able to drop the illegal packets in ovn-controller

Copy link
Collaborator

@dceara dceara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! The northd changes make sense; but we need to make sure we don't change the behavior of only replying if the external port is bound locally.

However, for this part:

OVN may now respond to illegal DHCP packets like src=0.0.0.0/dst=1.65.5.1 but we have COPP for this and we should be able to drop the illegal packets in ovn-controller

AFAICT pinctrl (ovn-controller) doesn't check for illegal packets like that. Don't we need to add a check there too?

LE: removed the note about external port, that was already how the PR behaved.

northd/northd.c Show resolved Hide resolved
@JacobTanenbaum JacobTanenbaum force-pushed the FDP-133-1 branch 2 times, most recently from db5508a to 24af092 Compare November 16, 2023 15:09
@JacobTanenbaum
Copy link
Contributor Author

@dceara does the check in pinctrl.c fit the required check?

@dceara
Copy link
Collaborator

dceara commented Nov 16, 2023

@dceara does the check in pinctrl.c fit the required check?

Don't we also need checks for DHCP_MSG_REQUEST?

controller/pinctrl.c Outdated Show resolved Hide resolved
controller/pinctrl.c Outdated Show resolved Hide resolved
controller/pinctrl.c Outdated Show resolved Hide resolved
@JacobTanenbaum JacobTanenbaum force-pushed the FDP-133-1 branch 3 times, most recently from 12e9593 to 8a77a62 Compare November 17, 2023 19:38
@dceara
Copy link
Collaborator

dceara commented Nov 20, 2023

LGTM overall but needs a few minor changes (reported by checkpatch):

$ ./utilities/checkpatch.py -1
== Checking 8a77a6226b7f ("reduce number of DHCP responder flows for LSPs") ==
ERROR: Author Jacob Tanenbaum <[email protected]> needs to sign off.
WARNING: Line is 88 characters long (recommended limit is 79)
#49 FILE: controller/pinctrl.c:2058:
            VLOG_WARN_RL(&rl, "DHCP REQUEST cannot be sent from an unassigned address");

WARNING: Line is 90 characters long (recommended limit is 79)
#64 FILE: northd/northd.c:6808:
                  "(ip4.src == {"IP_FMT", 0.0.0.0}  && ip4.dst == {%s, 255.255.255.255})",

Lines checked: 155, Warnings: 2, Errors: 1

@JacobTanenbaum
Copy link
Contributor Author

@dceara fixed the checkpath issues

currently for every LSP two DHCP responder flows are created. These two
flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0}  && ip4.dst == {1.65.5.1, 255.255.255.255})

there is potential for a faulty DHCP discovery and DHCP Request packet getting through
  - added a check in pinctrl.c to check for illegal dhcp discovery packet sending to host

Signed-off-by: Jacob Tanenbaum <[email protected]>
@dceara
Copy link
Collaborator

dceara commented Nov 21, 2023

@dceara does the check in pinctrl.c fit the required check?

Don't we also need checks for DHCP_MSG_REQUEST?

Just to close the loop on this one, it's valid to get requests from both unassigned (0.0.0.0) and unicast IPs.

Copy link
Collaborator

@dceara dceara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, @numansiddique wdyt, do you mind having a second look?

@numansiddique
Copy link
Collaborator

Ack. I'll take a look

@numansiddique
Copy link
Collaborator

I've submitted the patch to the mailing list - https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/

I'll apply the patch after taking a look.

ovsrobot pushed a commit to ovsrobot/ovn that referenced this pull request Nov 24, 2023
Currently for every LSP two DHCP responder flows are created. These two
flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0}  && ip4.dst == {1.65.5.1, 255.255.255.255})

there is potential for a faulty DHCP discovery and DHCP Request packet getting through
  - added a check in pinctrl.c to check for illegal dhcp discovery packet sending to host

Submitted-at: ovn-org#224
Signed-off-by: Jacob Tanenbaum <[email protected]>
Acked-by: Dumitru Ceara <[email protected]>
Signed-off-by: 0-day Robot <[email protected]>
numansiddique pushed a commit that referenced this pull request Nov 27, 2023
Currently for every LSP two DHCP responder flows are created. These two
flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0}  && ip4.dst == {1.65.5.1, 255.255.255.255})

there is potential for a faulty DHCP discovery and DHCP Request packet getting through
  - added a check in pinctrl.c to check for illegal dhcp discovery packet sending to host

Submitted-at: #224
Signed-off-by: Jacob Tanenbaum <[email protected]>
Acked-by: Dumitru Ceara <[email protected]>
Signed-off-by: Numan Siddique <[email protected]>
@numansiddique
Copy link
Collaborator

Applied the patch manually. Closing the PR.

@JacobTanenbaum - Thanks for the contribution. Added your name to AUTHORS.rst too

LorenzoBianconi pushed a commit to LorenzoBianconi/ovn that referenced this pull request Nov 18, 2024
Currently for every LSP two DHCP responder flows are created. These two
flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0}  && ip4.dst == {1.65.5.1, 255.255.255.255})

there is potential for a faulty DHCP discovery and DHCP Request packet getting through
  - added a check in pinctrl.c to check for illegal dhcp discovery packet sending to host

Submitted-at: ovn-org#224
Signed-off-by: Jacob Tanenbaum <[email protected]>
Acked-by: Dumitru Ceara <[email protected]>
Signed-off-by: Numan Siddique <[email protected]>
numansiddique pushed a commit that referenced this pull request Nov 26, 2024
Currently for every LSP two DHCP responder flows are created. These two
flows are almost exactly the same differing only in the match.

ex.
Unicast flow (for RENEW/REBIND):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 1.65.5.169 && ip4.dst == {1.65.5.1, 255.255.255.255} && udp.src == 68 && udp.dst == 67"

Broadcast flow (for DISCOVER):
"match":"inport == \"0e4b7821-b5ae-4bff-9424-d7245c679150\" && eth.src == fa:16:3e:68:5e:c1 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67"

I consolidated the flows to use the conjunctive match (ip4.src == {1.65.5.169, 0.0.0.0}  && ip4.dst == {1.65.5.1, 255.255.255.255})

there is potential for a faulty DHCP discovery and DHCP Request packet getting through
  - added a check in pinctrl.c to check for illegal dhcp discovery packet sending to host

Submitted-at: #224
Signed-off-by: Jacob Tanenbaum <[email protected]>
Acked-by: Dumitru Ceara <[email protected]>
Signed-off-by: Numan Siddique <[email protected]>
(cherry picked from commit 2132acb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants