On Tue, Aug 18, 2026 at 7:45 PM Jacob Tanenbaum via dev <
[email protected]> wrote:

> chassis_build_encaps() writes the default encap ip to the key
> "is_default" and select_default_encap_ip() read it incorrectly from
> key "default-encap-ip". This patch corrects the key to be read from
> "is_default". The test exercises the codepath fixed by this patch.
>
> This bug was only triggered by multicast/broadcast traffic with
> flow-based tunnels, multiple encap IPs, and no per-VIF encap-ip set.
>
>
nit: Missing Fixes tag.


> Assisted-by: Claude Opus 4.8, ClaudeCode
> Reported-at: https://redhat.atlassian.net/browse/FDP-4222
> Signed-off-by: Jacob Tanenbaum <[email protected]>
>
> diff --git a/controller/local_data.c b/controller/local_data.c
> index af6c75b40..830344352 100644
> --- a/controller/local_data.c
> +++ b/controller/local_data.c
> @@ -858,7 +858,7 @@ select_default_encap_ip(const struct sbrec_chassis
> *chassis,
>              default_ip = encap->ip;
>          }
>
> -        if (smap_get_bool(&encap->options, "default-encap-ip", false)) {
> +        if (smap_get_bool(&encap->options, "is_default", false)) {
>              default_ip = encap->ip;
>              break;  /* Found explicit default */
>          }
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 9c4698d76..868998250 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -32614,6 +32614,57 @@ AT_CLEANUP
>  ])
>
>
> +OVN_FOR_EACH_NORTHD([
> +AT_SETUP([default encap-ip selection for multicast with flow-based
> tunnels])
> +CHECK_SCAPY
> +ovn_start
> +net_add n1
> +
> +check ovn-nbctl ls-add ls1
> +
> +for i in 1 2; do
> +    sim_add hv$i
> +    as hv$i
> +    ovs-vsctl add-br br-phys
> +    ovn_attach n1 br-phys 192.168.0.${i}1
> +    ovs-vsctl set open .
> external_ids:ovn-encap-ip=192.168.0.${i}1,192.168.0.${i}2
> +    ovs-vsctl set open . external_ids:ovn-enable-flow-based-tunnels=true
> +    ovs-vsctl set open . external_ids:ovn-encap-ip-default=192.168.0.${i}2
> +
> +    ovs-vsctl add-port br-int vif${i}1 -- set Interface vif${i}1 \
> +        external_ids:iface-id=lsp$i \
> +        options:tx_pcap=hv$i/vif${i}1-tx.pcap \
> +        options:rxq_pcap=hv$i/vif${i}1-rx.pcap
>

nit: Missing check for all ovs-vsctl calls.


> +    check ovn-nbctl lsp-add ls1 lsp$i -- \
> +        lsp-set-addresses lsp$i "f0:00:00:00:00:${i}1 10.0.0.${i}1"
> +done
> +
> +wait_for_ports_up
> +check ovn-nbctl --wait=hv sync
> +
> +dnl Use an unknown target IP so the ARP request is not intercepted by
> OVN's
> +dnl ARP responder and is flooded via the multicast group instead.
> +packet=$(fmt_pkt "Ether(dst='ff:ff:ff:ff:ff:ff', src='f0:00:00:00:00:11')
> / \
> +                  ARP(op=1, hwsrc='f0:00:00:00:00:11', psrc='10.0.0.11', \
> +                      hwdst='00:00:00:00:00:00', pdst='10.0.0.99')")
> +
> +as hv1
> +AT_CHECK([ovs-vsctl wait-until interface ovn-geneve 'ofport>0'])
> +
> +dnl Broadcast ARP for an unknown target triggers the multicast flood path
> +dnl which calls fanout_to_chassis_flow_based().  The tunnel endpoints must
> +dnl use the configured default encap IPs, not the first ones in the list.
> +OVS_WAIT_UNTIL([
> +    trace_output=$(ovs-appctl ofproto/trace br-int in_port=vif11 $packet)
> +    echo "$trace_output" | grep -q "set_field:192.168.0.22->tun_dst"
> +])
> +AT_CHECK([echo "$trace_output" | grep -q
> "set_field:192.168.0.12->tun_src"])
> +
> +OVN_CLEANUP([hv1],[hv2])
> +AT_CLEANUP
> +])
> +
> +
>  OVN_FOR_EACH_NORTHD([
>  AT_SETUP([Load Balancer LS hairpin OF flows])
>  ovn_start
> --
> 2.55.0
>
> _______________________________________________
> dev mailing list
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
Thank you Jacob,

applied to main and 26.03 with those nits taken care of.

Regards,
Ales
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to