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
