-
Notifications
You must be signed in to change notification settings - Fork 261
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
Conversation
There was a problem hiding this 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.
db5508a
to
24af092
Compare
@dceara does the check in pinctrl.c fit the required check? |
Don't we also need checks for DHCP_MSG_REQUEST? |
24af092
to
4a18667
Compare
12e9593
to
8a77a62
Compare
LGTM overall but needs a few minor changes (reported by checkpatch):
|
8a77a62
to
d2fc302
Compare
@dceara fixed the checkpath issues |
d2fc302
to
d81bb65
Compare
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]>
d81bb65
to
79777f7
Compare
Just to close the loop on this one, it's valid to get requests from both unassigned (0.0.0.0) and unicast IPs. |
There was a problem hiding this 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?
Ack. I'll take a look |
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. |
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]>
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]>
Applied the patch manually. Closing the PR. @JacobTanenbaum - Thanks for the contribution. Added your name to AUTHORS.rst too |
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]>
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)
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