Repository navigation
Conversation
The "ovn-nbctl show" command did not display the peer field of logical router ports, making it hard to see direct router-to-router connections configured via LRP.peer. Display the peer name for each logical router port that has one configured, improving debuggability of router peering topologies. Reported-at: https://redhat.atlassian.net/browse/FDP-3716 Assisted-by: Claude Opus 4.6, OpenCode Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
When multi-tier ACLs are configured, "ovn-nbctl acl-list" does not display any tier information, making it difficult to see which tier each ACL belongs to without querying the database directly. Display a "[tier N]" annotation for each ACL showing its tier value. Sort ACLs by tier (ascending) before priority so that ACLs belonging to the same tier are grouped together. The ascending order matches the evaluation order of tiers. Previously, tier was compared after priority and in descending order. Reported-at: https://redhat.atlassian.net/browse/FDP-3585 Assisted-by: Claude Opus 4.6, OpenCode Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
The column was added to expose DGP information to the CMS but ovn-northd never reads it and shouldn't be notified about its changes. The CMS should also never write to it. Omit updates to it, otherwise ovn-northd unnecessarily wakes up after its own transaction that set it was committed in the NB. Even worse, these updates break incremental processing of router datapaths (if they're the only changes that happened in the NB) because lr_changes_can_be_handled() assumes it's a relevant LRP change. Update the existing tests accordingly. Fixes: 19164b0 ("Expose distributed gateway port information in NB DB") Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
Tests that required "UDP echo" service used custom logic to ensure that the "nc" process and all of its children got killed on the cleanup. This change extracts that custom logic into a reusable macro NETNS_START_UDP_ECHO. Signed-off-by: Martin Kalcok <martin.kalcok@gmail.com> Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
Commit b337750 ("northd: Incremental processing of VIF changes in 'northd' node.") skipped non-VIF ports from processing. However, "remote" ports are almost identical to VIF ports and it turns out that incremental processing works fine for them too (if enabled). This patch enables that processing path. Assisted-by: Claude Opus 4.6, Claude Code Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
Windows build was broken since the split from OVS. OVS also recently fully dropped support for building and running on Windows. Let's remove the bits of the Windows build system to avoid any confusion. Some notes: * debian/copyright.in is very outdated. Only removing bits directly related to the Windows build. * Comment in ovn-controller-vtep.at is removed without touching any code because it's just an outdated comment that should've been removed while moving to Python 3. * m4/absolute-header.m4 still has one Windows reference, but it is coming from the original sources and it should remain. * HOST_NAME_MAX is needed for BSD/OSX, not only for Windows. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Mark Michelson <mmichels@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com>
DHCP client extends its lease by unicasting a DHCPREQUEST to its
original DHCP server when the T1 timer fires (typically at 50% of
the lease). If that DHCPREQUEST gets no response, the T2 timer
fires (typically at 87.5% of the lease) and the client enters the
REBINDING state, where it broadcasts a DHCPREQUEST using its
currently leased IP as the source address (rather than 0.0.0.0).
Today OVN's DHCP relay only matches DHCPREQUEST packets whose source
IP is 0.0.0.0, so the broadcast DHCPREQUEST sent by a client in the
REBINDING state is not matched by any relay flow and is dropped.
The lease cannot be renewed through the relay and the client
eventually falls back to a fresh DISCOVER.
Extend the relay to also forward DHCPREQUEST packets whose source IP
lies in the relay LRP's subnet by widening the source-IP match of
the DHCP relay request flows to the set
ip4.src == {0.0.0.0, <lrp_cidr>}, where <lrp_cidr> is the CIDR of
the relay Logical_Router_Port. The set is applied to:
- The priority-100 logical switch flow in ls_in_l2_lkup that
forwards client DHCP broadcasts to the relay LRP-attachment
port.
- The logical router lr_in_ip_input priority-110
dhcp_relay_req_chk flow.
- The lr_in_dhcp_relay_req priority-100 forward and priority-1
drop flows.
Fixes: dce4abf ("northd, tests: DHCP Relay Agent support for overlay IPv4 subnets.")
Signed-off-by: Naveen Yerramneni <naveen.yerramneni@nutanix.com>
Acked-by: Aditya Mehakare <aditya.mehakare@nutanix.com>
Acked-by: Huzaifa Calcuttawala <huzaifa.c@nutanix.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
In northd, Logical_Switch_Port.tag is set from tag_request. A nonzero request is copied directly into tag. A request of 0 on a child port (one with parent_name set) is replaced by a tag that is unique within the parent's scope. Currently, tag is not cleared when tag_request is removed, or when tag_request=0 on a port without parent_name. The stale derived tag propagates to SB Port_Binding.tag, and ovn-controller keeps tagging packets after the CMS removed the request. This patch clears the derived tag in both cases. It also stops counting tags as in-use by a child port once their request is gone, so the parent's pool is freed correctly. Added tests for three transitions: clearing tag_request on a child port, clearing tag_request on a non-child port, and setting tag_request=0 on a non-child port. Signed-off-by: Mykola Yurchenko <myurchenko@nvidia.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
…nge-netlink. The datapath argument passed to re_nl_sync_routes() is never used so it should be removed. Acked-by: Mairtin O'Loingsigh <moloings@redhat.com> Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Users should be able to configure two logical routers that simultaneously interact with the same host routing table (vrf). This is accomplished by first processing all the datapaths before syncing the vrf tables. Now re_nl_sync_routes() is only called once per vrf table. Reported-at: https://redhat.atlassian.net/browse/FDP-3472 Reported-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Mairtin O'Loingsigh <moloings@redhat.com> Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Load_Balancer health checks were silently failing for baremetal pool
members whose backend Logical_Switch_Port has type=external on a
Logical_Switch that has a localnet port (typical for Neutron and the
ovn-octavia-provider baremetal driver on a provider VLAN).
When the controller emits a health-check probe it stamps the source
MAC with $svc_monitor_mac (or the LRP MAC) and sends it out the LRP.
The reply from the baremetal member re-enters br-int via the localnet
port, so at S_SWITCH_IN_L2_LKUP MFF_LOG_INPORT carries the localnet
LSP's tunnel_key, not the backend LSP's. The per-backend reply
lflow's match "inport == <backend> && ..." never fires, and even the
generic per-LS "eth.dst == $svc_monitor_mac" lflow that calls
handle_svc_check(inport) feeds pinctrl the localnet tunnel_key,
which pinctrl_find_svc_monitor() cannot resolve to a service monitor.
The CMS therefore concludes the member is down.
Fix the issue inside the logical switch ingress pipeline at the
earliest possible stage so that every downstream lflow (HM reply,
ARP responder, DHCP, FDB, ACL, ...) observes a sensible inport for
the external LSP.
For each external LSP that lives on a switch with a localnet port,
install a new lflow at S_SWITCH_IN_CHECK_PORT_SEC priority 75:
match : inport == <localnet_port> && eth.src == <external_mac>
action: flags.localnet = 1; inport = <external_lsp>; next;
The match is specific enough (combined eth.src + localnet inport)
that it does not affect any other localnet traffic. Setting
flags.localnet here preserves the semantics that
build_lswitch_from_localnet_op() and build_lswitch_learn_fdb_op()
previously provided at S_SWITCH_IN_LOOKUP_FDB, which would no longer
fire for external-LSP-sourced packets after the rewrite.
With this rewrite in place:
* The original per-backend HM reply lflow at S_SWITCH_IN_L2_LKUP
("inport == <backend>" / "handle_svc_check(inport);") works
without modification.
* The generic per-LS "eth.dst == $svc_monitor_mac" lflow uses the
backend LSP's tunnel_key when calling handle_svc_check(inport),
so pinctrl_find_svc_monitor() succeeds for the
$svc_monitor_mac-sourced probe case as well.
Two follow-on adjustments are required because they depended on
MFF_LOG_INPORT being the localnet port for external-LSP traffic:
* build_lswitch_dhcp_options_and_response() now calls
build_dhcpv4/v6_options_flows() with op (the external LSP) as
the inport for is_external, eliminating the previous
per-localnet-port enumeration.
* build_drop_arp_nd_flows_for_unbound_router_ports() now matches
on op->json_key (the external LSP) instead of the localnet
port.
tests/ovn-northd.at gains a unit test that exercises a regular VIF
backend on a tenant LS and a type=external backend on a provider LS
with a localnet, asserting the original HM reply lflow forms and the
new inport-rewrite lflow. An additional scenario deletes the
localnet port and verifies the inport-rewrite lflow is removed.
tests/ovn.at "external logical port" is updated to assert that the
DHCPv4/v6 controller OF flows installed for an external port carry
reg14 == external_lsp_key (the rewritten inport), not the localnet
port's key.
Signed-off-by: JayGue Lee <enginrect@gmail.com>
Acked-by: Numan Siddique <numans@ovn.org>
Signed-off-by: Numan Siddique <numans@ovn.org>
This is one missed bit of the old Windows support. Interestingly, ovn-dbctl and ovn-trace didn't stop their services. Fixes: accc3e7 ("treewide: Remove shards of Windows support.") Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Mark Michelson <mmichels@redhat.com>
When a port with a globally-administered MAC address (e.g., 00:00:00:00:00:04) is added to br-int, OVS may recalculate the bridge datapath ID if no explicit datapath-id is configured. The new DPID causes OVS to tear down all OpenFlow connections to the bridge, since there is no OpenFlow message to notify the controller of a DPID change. This triggers ovn-controller's ofctrl_seqno_flush(), which resets the internal sequence counter to 0. If a flow update from before the reconnection is still in-flight, ofctrl_put() detects that the new req_cfg is smaller than the pending one and emits "req_cfg regressed from 2 to 1". Fix this by deriving a stable other-config:datapath-id from the bridge name in the ADD_BR macro. This ensures the DPID never changes when ports are added or removed, preventing spurious OpenFlow reconnections during tests. Assisted-by: Claude Opus 4.6, OpenCode Acked-by: Xavier Simonart <xsimonar@redhat.com> Signed-off-by: Ales Musil <amusil@redhat.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Lucas Vargas Dias <lucas.vdias@magalu.cloud> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
This reverts commit 609c913.
This reverts commit accc3e7.
Resync with ovn-org/ovn main (8d5aa2c). Upstream removed the remaining Windows build-system and source support in two commits: accc3e7 treewide: Remove shards of Windows support. 609c913 treewide: Remove Windows service handling. This fork continues to target Windows, so both removals are reverted before merging. The merge therefore brings in only upstream's functional changes (dynamic routing / route-exchange, northd LB health checks, DHCP relay, nbctl/test updates) while preserving this fork's Windows build (CMake overlay, ovsext, MSVC bits) intact.
GitHub renders README.md in preference to README.rst, so add a Markdown README describing this dbosoft Windows fork: what it forks and why, the OVS Windows submodule dependency, the CMake/MSVC build, and fork-specific contact info. The upstream README.rst is kept untouched to minimize divergence from upstream, mirroring the dbosoft OVS fork.
fw2568
force-pushed
the
windows/resync-upstream-main
branch
from
June 9, 2026 09:20
17b48ae to
3e3d752
Compare
fw2568
changed the title
Author
|
Superseded by #8, which redoes this as a clean patch-on-top resync (replaying the ovs-patches/ovn series on upstream/main) instead of merge+revert, per maintainer feedback. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resyncs the fork with
ovn-org/ovnmain (8d5aa2c) while preserving this fork's Windows support, and adds a Windows-forkREADME.md.Upstream resync, Windows kept. Upstream removed the remaining Windows build-system and source support in two commits (
accc3e71b"Remove shards of Windows support" and609c91314"Remove Windows service handling"). Since this fork targets Windows — the same situation as the OVS fork — both removals are reverted before merging, so the merge brings in only upstream's functional changes (dynamic routing / route-exchange, northd LB health checks, DHCP relay, nbctl/test updates) and leaves the Windows build (CMake overlay, ovsext via theovssubmodule, MSVC bits) intact. Net diff vsdbosoft-maincontains no deletions of Windows/CMake/build files.README. Adds a Markdown
README.mddescribing the fork, its OVS-Windows submodule dependency, and the CMake/MSVC build. The upstreamREADME.rstis kept untouched to minimize divergence (GitHub rendersREADME.mdpreferentially), mirroring the dbosoft OVS fork.