On Fri, 2024-12-06 at 10:31 +0100, Dumitru Ceara wrote: > On 12/6/24 10:29 AM, martin.kal...@canonical.com wrote: > > Hi Dumitru, > > > > On Fri, 2024-12-06 at 10:01 +0100, Dumitru Ceara wrote: > > > On 8/23/24 2:58 PM, Martin Kalcok via discuss wrote: > > > > Hello OVN enthusiasts o/ > > > > I noticed that when periodic IPv6 Router Advertisements are > > > > enabled > > > > on LRP [0], they wont get forwarded to the external networks. > > > > I’m > > > > just wondering if it’s intentional, or a bug. I have following > > > > simple setup: > > > > > > Hi Martin, > > > > > > I think this bug report fell through the cracks but MJ brought it > > > up > > > again during yesterday's IRC meeting. Thanks for that, MJ! > > > > > > > > > > > alice | | ovn-host > > > > | | > > > > eth1 -------- eth1 -- SW-EXT --- R1 > > > > | | > > > > > > > > * alice is external host connected via physical network > > > > * ovn-host runs OVN+OVS services > > > > * SW-EXT is LS > > > > * R1 is LR with interface plugged to SW-EXT > > > > > > > > Below are (what I think) relevant details: > > > > > > > > # ovs-vsctl show > > > > 7c17d701-cc3d-4804-8094-5f92e090daa8 > > > > Bridge br-ext > > > > Port br-ext > > > > Interface br-ext > > > > type: internal > > > > Port patch-ext-patch-to-br-int > > > > Interface patch-ext-patch-to-br-int > > > > type: patch > > > > options: {peer=patch-br-int-to-ext-patch} > > > > Port eth1 > > > > Interface eth1 > > > > Bridge br-int > > > > fail_mode: secure > > > > datapath_type: system > > > > Port br-int > > > > Interface br-int > > > > type: internal > > > > Port patch-br-int-to-ext-patch > > > > Interface patch-br-int-to-ext-patch > > > > type: patch > > > > options: {peer=patch-ext-patch-to-br-int} > > > > ovs_version: “3.4.0" > > > > > > > > # ovn-nbctl show > > > > switch aaa80b25-8168-4944-bcb9-aede4d3f4c94 (SW-EXT) > > > > port lsp-ext > > > > type: router > > > > router-port: lrp-ext > > > > port ext-patch > > > > type: localnet > > > > addresses: ["unknown"] > > > > router d75c995e-4d9b-4bd1-af18-9cd24c248f44 (R1) > > > > port lrp-ext > > > > mac: "00:00:02:00:00:01" > > > > ipv6-lla: "fe80::200:2ff:fe00:1" > > > > networks: ["10.42.234.1/24", "fd12:3456:789a:1::/64”] > > > > > > > > # ipv6_ra options on “lrp-ext” in NB > > > > ipv6_ra_configs : {address_mode=slaac, max_interval=“4", > > > > min_interval=“3", send_periodic="true”} > > > > > > > > # the same options correctly translated to SB options in > > > > “port_binding” table > > > > options : {ipv6_ra_address_mode=slaac, > > > > ipv6_ra_max_interval="4", ipv6_ra_min_interval="3”, > > > > ipv6_ra_prefixes="fd12:3456:789a:1::/64", ipv6_ra_prf=MEDIUM, > > > > ipv6_ra_send_periodic="true”, > > > > ipv6_ra_src_addr="fe80::200:2ff:fe00:1", > > > > ipv6_ra_src_eth="00:00:02:00:00:01", l3gateway-chassis=movn1, > > > > peer=lsp-ext} > > > > > > > > I can see that the packets are generated by controller: > > > > > > > > Aug 23 10:00:17 movn1 ovn-controller[19122]: > > > > ovs|00161|vconn(ovn_pinctrl0)|DBG|unix:/var/snap/microovn/commo > > > > n/ru > > > > n/switch//br-int.mgmt: sent (Success): OFPT_PACKET_OUT (OF1.5) > > > > (xid=0x3de): in_port=CONTROLLER actions=set_field:0x2- > > > > > metadata,set_field:0x1->reg14,set_field:0x10/0x10- > > > > > reg10,resubmit(CONTROLLER,8) data_len=110 Aug 23 10:00:17 > > > > > movn1 > > > > ovn-controller[19122]: > > > > icmp6,vlan_tci=0x0000,dl_src=00:00:02:00:00:01,dl_dst=33:33:00: > > > > 00:0 > > > > 0:01,ipv6_src=fe80::200:2ff:fe00:1,ipv6_dst=ff02::1,ipv6_label= > > > > 0x00 > > > > 000,nw_tos=0,nw_ecn=0,nw_ttl=255,nw_frag=no,icmp_type=134,icmp_ > > > > code > > > > =0 icmp6_csum:893b > > > > > > > > However listening on “eth1” either on “alice” or on “ovn-host”, > > > > the > > > > RAs never show up. Note that if I plug another LSP into SW-EXT, > > > > those RAs show up on an interface bound to that LSP. > > > > I did a little bit of digging and found that these RA packets > > > > are > > > > dropped by a rule that’s supposed to prevent leaking of “local > > > > only” traffic through localnet ports [1]. > > > > > > I think this was intentional (CC Ihar) to cover the case when a > > > distributed OVN router (without any gateway ports) has periodic > > > RA > > > enabled and is connected to the fabric via a localnet switch. > > > > Thanks for providing more context. I originally missed the > > explanation > > in the commit that introduced this change [2]. > > > > > > > > > The reason why I think this is unintentional is that solicited > > > > RAs > > > > in reply to NS requests from “alice” are answered to the > > > > external > > > > network without any issues. > > > > > > > > > > This part is indeed problematic. Ihar, what do you think, should > > > we > > > block solicited RAs too? Can we make it so only one chassis > > > sends > > > them out? > > > > > > > What would be the best approach to fixing this? > > > > > > > > > > Martin, MJ, if I understand correctly, the router port where > > > you're > > > trying to enable periodic RAs is a gateway port (so it will be > > > bound > > > to > > > exactly on chassis). Maybe a way forward is to change the > > > behavior > > > introduced in [1] and only enforce it if the router is not a > > > gateway > > > router and if the router port originating the RA is not a gateway > > > port. > > > > > > Would that work? > > > > Yes, this sounds good to me. Our specific use-case is indeed to > > make > > this work primarily for GW routers. However, would it be possible > > to > > also exempt Distributed Gateway Ports? Those also reside only on > > one > > chassis at a time. > > > > Yes, that's what I meant when I said "is not a gateway port" (I'm > never > 100% sure about the correct terminology even after all this time :) > ).
no worries :D I just wanted to ensure that we are on the same page. > > Would you happen to have time to propose a patch that does that? > Yes, MJ has her eyes on this fix and now with your clarification there's a clear way forward. As she mentioned, this is one of the blockers for BGP unnumbered integration, so we aim to fix this before code freeze. Thanks again, Martin. > Thanks! > > > > > > > > Thanks for any insights, > > > > Martin. > > > > > > > > [0] https://man7.org/linux/man-pages/man5/ovn-nb.5.html (search > > > > for > > > > “send_periodic”) > > > > [1] > > > > https://github.com/ovn-org/ovn/blob/32fb58665f93ef033e5a0e748a4f5ee1ed10e03b/controller/physical.c#L1859-L1867 > > > > > > Regards, > > > Dumitru > > > > > > > Martin. > > > > [2] > > https://github.com/ovn-org/ovn/commit/14c6dac51dc87747707ffe678e777277ca776d84 > > > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss