On 5/14/24 11:25, Justin Lamp wrote:
> Hi Dumitru,
>
> in case you did not see the attachment. I already did an ovn-trace and
> added it to the file.
>
Ah, sorry about that, I missed it.
You should probably re-run the trace and pass "--ct new" twice, for both
zones (ingress and egress), e.g.:
ovn-trace --ct new 'inport == ...'
Otherwise, ovn-trace will assume the conntrack entry is established for
the egress pipeline. But we're actually trying to simulate the first
UDP packet processing.
From your ofproto/trace (that does assume ct_state=+new+trk by default)
I see the packet is tunneled to a remote hypervisor (I guess that's
where the destination mac address resides):
Megaflow:
recirc_id=0x20b0e97,ct_state=+new-est-rel-rpl-inv+trk,ct_mark=0/0x1,eth,ip,in_port=783,dl_src=fa:16:3e:14:b3:54,dl_dst=fa:16:3e:12:8a:91,nw_dst=10.0.0.128/25,nw_ecn=0,nw_frag=no
Datapath actions:
ct(commit,zone=1247,mark=0/0x1,nat(src)),set(tunnel(tun_id=0x254,dst=10.77.2.57,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x30005}),flags(df|csum|key))),3
Can you please try to run an ofproto/trace on the remote hypervisor too.
It requires some careful work to get the metadata in place but an
example on how to do that is here:
https://gist.github.com/trozet/343abe2721e59b1980c8544ec684bc02#file-geneve_ofproto-txt-L11-L52
The most important part is to get the values of the egress port SB
datapath key and ingress/egress port bindings, in the gist above:
Summarizing:
# sb_datapath=4
# sb_inport=1
# sb_outport=3
Hope this helps,
Best regards,
Dumitru
> Thanks!
> Best regards,
> Justin Lamp
>
> Am 14.05.24 um 10:55 schrieb Dumitru Ceara:
>> On 4/26/24 12:50, Justin Lamp via discuss wrote:
>>> Hey there,
>>>
>>> we are on OVN 23.06.3 + OVS 3.1.2 and are facing an issue with the ACLs.
>>> For some odd reason some UDP Packets are not dropped. I attached all the
>>> information I was able to gather. The attached traces show the Wireguard
>>> connection between two VMs on Port 51871 (src+dst). This connection should
>>> not work as no UDP Ports except 6081 and 8472 are allowed. It still does
>>> tho.
>>>
>>> This is the SG representation in Neutron:
>>>
>>> ❯ openstack security group rule list c987f508-a7de-4bb5-9333-849c129a22b8
>>> +--------------------------------------+-------------+-----------+-----------+-------------+-----------+--------------------------------------+----------------------+
>>> | ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote
>>> Security Group | Remote Address Group |
>>> +--------------------------------------+-------------+-----------+-----------+-------------+-----------+--------------------------------------+----------------------+
>>> | 01c904db-57be-437b-9c74-12f0cbad1460 | udp | IPv4 | 0.0.0.0/0 | 8472:8472
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 0b2daa78-b12e-4776-ba49-e9994869d8a8 | tcp | IPv4 | 0.0.0.0/0 |
>>> 10250:10250 | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 154b9565-67f8-4f4b-9838-1dbda43134fe | tcp | IPv4 | 0.0.0.0/0 | 22:22 |
>>> ingress | None | None |
>>> | 17c38fc3-4278-457d-8739-6864afbb2526 | None | IPv4 | 0.0.0.0/0 | | egress
>>> | None | None |
>>> | 1d8f5aab-dfe0-4ed2-9272-6a9c1c0c609f | udp | IPv4 | 0.0.0.0/0 | 6081:6081
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 1f8a26db-4779-4678-ab2d-0f0cb9eeef9c | tcp | IPv4 | 0.0.0.0/0 | 4244:4244
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | 20faa684-8161-4912-b4f3-a3eae04ce901 | tcp | IPv4 | 0.0.0.0/0 |
>>> 10250:10250 | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | 226b8f5f-03d3-43ab-a0c3-9161d9120794 | tcp | IPv4 | 0.0.0.0/0 | 4250:4250
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | 30514756-490b-43b5-bbab-81a0a5acc2ad | None | IPv6 | ::/0 | | egress |
>>> None | None |
>>> | 40f33186-4362-427f-bf8c-3f46d7aca525 | tcp | IPv4 | 0.0.0.0/0 | 4250:4250
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 438e32b1-c35c-42ba-89bc-a63139c0737c | tcp | IPv4 | 0.0.0.0/0 | 4240:4240
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 463611cf-9732-44a2-8f83-4ef54b4b6e0e | tcp | IPv4 | 0.0.0.0/0 | 4244:4244
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | 6cd71132-c560-4c3b-98c0-03757e91a04c | icmp | IPv4 | 0.0.0.0/0 | |
>>> ingress | None | None |
>>> | 894349a4-bf1b-4c4f-a33f-df5e1c3a5e83 | tcp | IPv4 | 0.0.0.0/0 |
>>> 30000:32767 | ingress | None | None |
>>> | 8f1991f1-6e6d-45e0-81c9-c4730aa27be1 | tcp | IPv4 | 0.0.0.0/0 | 4240:4240
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | 9e25f25e-6bfe-48ae-88e0-ac06253199cb | tcp | IPv4 | 0.0.0.0/0 | 9100:9100
>>> | ingress | c987f508-a7de-4bb5-9333-849c129a22b8 | None |
>>> | cb020375-066d-4547-b268-be75ac1dad34 | udp | IPv4 | 0.0.0.0/0 | 6081:6081
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | d419edce-217f-4816-b214-f93a148bc8f6 | tcp | IPv4 | 0.0.0.0/0 | 9100:9100
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> | e7fbaf7f-45ba-4099-99a1-1a2994670aad | udp | IPv4 | 0.0.0.0/0 | 8472:8472
>>> | ingress | afee7436-fd26-4d6e-b2bb-fb955ae6fd4f | None |
>>> +--------------------------------------+-------------+-----------+-----------+-------------+-----------+--------------------------------------+----------------------+
>>> Thanks!
>>> Best regards,
>>> Justin Lamp
>> Hi Justin,
>>
>> I'm not sure if this is the same thing as Brendan reported here [0] but
>> it might help to run an ovn-trace to simulate the logical flow table
>> execution that would happen for wireguard packets.
>>
>> [0] https://mail.openvswitch.org/pipermail/ovs-discuss/2024-May/053136.html
>>
>> Best regards,
>> Dumitru
>>
>
>
> --
> Justin Lamp
> Systems Engineer
>
> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk, Sebastian Saemann | AG Nuernberg HRB25207
> https://www.netways.de | justin.l...@netways.de
>
> ** stackconf 2024 - June | Berlin - https://stackconf.eu **
> ** OSMC 2024 - November | Nuremberg - https://osmc.de **
> ** NETWAYS Web Services - https://nws.netways.de **
> ** NETWAYS Trainings - https://netways.de/trainings **
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
