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
<[email protected]> 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 <[email protected]>
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Regards,
Vladislav Odintsov
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
