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/common/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 :) ).
Would you happen to have time to propose a patch that does that?
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
