On 12/6/24 2:55 PM, martin.kal...@canonical.com wrote:
> 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.
>
FWIW, this is a bug fix in my opinion so it can go in at any time.
Regards,
Dumitru
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
