I’m sorry, of course I meant gateway_port instead of logical_port: gateway_port: optional weak reference to Logical_Router_Port A distributed gateway port in the Logical_Router_Port table where the NAT rule needs to be applied.
When multiple distributed gateway ports are configured on a Logical_Router, applying a NAT rule at each of the distributed gateway ports might not be desired. Consider the case where a logical router has 2 distributed gateway port, one with networks 50.0.0.10/24 and the other with networks 60.0.0.10/24. If the logical router has a NAT rule of type snat, logical_ip 10.1.1.0/24 and exter‐ nal_ip 50.1.1.20/24, the rule needs to be selectively applied on matching packets entering/leaving through the distributed gateway port with networks 50.0.0.10/24. When a logical router has multiple distributed gateway ports and this column is not set for a NAT rule, then the rule will be applied at the distributed gateway port which is in the same network as the external_ip of the NAT rule, if such a router port exists. If logical router has a single dis‐ tributed gateway port and this column is not set for a NAT rule, the rule will be applied at the dis‐ tributed gateway port even if the router port is not in the same network as the external_ip of the NAT rule. On 15 Mar 2023, at 20:05, Vladislav Odintsov via discuss <ovs-discuss@openvswitch.org> wrote: Hi, since you’ve configured multiple LRPs with GW chassis, you must supply logical_port for NAT rule. Did you configure it? You should see appropriate message in ovn-northd logfile. logical_port: optional string The name of the logical port where the logical_ip resides. This is only used on distributed routers. This must be specified in order for the NAT rule to be pro‐ cessed in a distributed manner on all chassis. If this is not specified for a NAT rule on a distrib‐ uted router, then this NAT rule will be processed in a centralized manner on the gateway port instance on the gateway chassis. On 15 Mar 2023, at 19:22, Tiago Pires via discuss <ovs-discuss@openvswitch.org> wrote: Hi, In an OVN Interconnection environment (OVN 22.03) with a few AZs, I noticed that when the OVN router has a SNAT enabled or DNAT_AND_SNAT, the traffic between the AZs is nated. When checking the OVN router's logical flows, it is possible to see the LSP that is connected into the transit switch with NAT enabled: Scenario: OVN Global database: # ovn-ic-sbctl show availability-zone az1 gateway ovn-central-1 hostname: ovn-central-1 type: geneve ip: 192.168.40.50 port ts1-r1-az1 transit switch: ts1 address: ["aa:aa:aa:aa:aa:10 169.254.100.10/24<http://169.254.100.10/24>"] availability-zone az2 gateway ovn-central-2 hostname: ovn-central-2 type: geneve ip: 192.168.40.221 port ts1-r1-az2 transit switch: ts1 address: ["aa:aa:aa:aa:aa:20 169.254.100.20/24<http://169.254.100.20/24>"] availability-zone az3 gateway ovn-central-3 hostname: ovn-central-3 type: geneve ip: 192.168.40.247 port ts1-r1-az3 transit switch: ts1 address: ["aa:aa:aa:aa:aa:30 169.254.100.30/24<http://169.254.100.30/24>"] OVN Central (az1) # ovn-nbctl show r1 router 3e80e81a-58b5-41b1-9600-5bfc917c4ace (r1) port r1-ts1-az1 mac: "aa:aa:aa:aa:aa:10" networks: ["169.254.100.10/24<http://169.254.100.10/24>"] gateway chassis: [ovn-central-1] port r1_s1 mac: "00:de:ad:fe:0:1" networks: ["10.0.1.1/24<http://10.0.1.1/24>"] port r1_public mac: "00:de:ad:ff:0:1" networks: ["200.10.0.1/24<http://200.10.0.1/24>"] gateway chassis: [ovn-central-1] nat df2b79d3-1334-4af3-8f61-5a46490f8a9c external ip: "200.10.0.101" logical ip: "10.0.1.2" type: "dnat_and_snat" OVN Logical Flows: table=3 (lr_out_snat ), priority=161 , match=(ip && ip4.src == 10.0.1.2 && outport == "r1-ts1-az1" && is_chassis_resident("cr-r1-ts1-az1")), action=(ct_snat_in_czone(200.10.0.101);) The datapath flows into OVS shows that the traffic is being nated and sent to the remote chassi gateway in AZ2: recirc_id(0x14),in_port(3),eth(src=aa:aa:aa:aa:aa:10,dst=aa:aa:aa:aa:aa:20),eth_type(0x0800),ipv4(dst=200.16.0.0/255.240.0.0,tos=0/0x3,frag=no<http://200.16.0.0/255.240.0.0,tos=0/0x3,frag=no>), packets:3, bytes:294, used:0.888s, actions:ct_clear,set(tunnel(tun_id=0xff0002,dst=192.168.40.221,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x10002}),flags(df|csum|key))),2 recirc_id(0x13),in_port(3),eth(),eth_type(0x0800),ipv4(src=10.0.1.2,frag=no), packets:3, bytes:294, used:0.888s, actions:ct(commit,zone=2,nat(src=200.10.0.101)),recirc(0x14) recirc_id(0),in_port(3),eth(src=00:de:ad:01:00:01,dst=00:de:ad:fe:00:01),eth_type(0x0800),ipv4(src=10.0.1.2,dst=200.20.0.0/255.255.255.0,ttl=64,frag=no<http://200.20.0.0/255.255.255.0,ttl=64,frag=no>), packets:3, bytes:294, used:0.888s, actions:set(e th(src=aa:aa:aa:aa:aa:10,dst=aa:aa:aa:aa:aa:20)),set(ipv4(ttl=63)),ct(zone=2,nat),recirc(0x13) Is this behavior expected by design or is it a bug? In my use case, I would like for the traffic between AZs to be routed instead of nated. Tiago Pires ‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’. ‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss Regards, Vladislav Odintsov _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss