Hi List, We are not developing new product with OVS NAT, however when test we found a question about the SNAT state flag.
Support I have the following flows: cookie=0x5847fc2c00000000, duration=54000.281s, table=50, n_packets=3928155, n_bytes=55143896854, priority=100,ip,metadata=0x1 actions=ct(table=51,zone=1,nat) cookie=0x5847fc2c00000000, duration=54009.712s, table=51, n_packets=229367, n_bytes=18280827, priority=100,ct_state=-snat,ct_zone=1,ip,metadata=0x1 actions=ct(commit,table=65,zone=1,nat(src=169.254.10.0)) cookie=0x5847fc2c00000000, duration=54009.712s, table=51, n_packets=3698797, n_bytes=55125616909, priority=100,ct_state=+snat,ct_zone=1,ip,metadata=0x1 actions=goto_table:65 When a unidirectional flow (IP_CT_NEW in conntrack term, for example ping a host that is not online) pass the rules, even the first packet is committed, the second and later packet still need match the flow with ct_state=-snat, after I have read the datapath code, it seems the following code have special process for unidirectional flow (ctinfo != IP_CT_NEW): if (info->nat & OVS_CT_NAT && ctinfo != IP_CT_NEW && ct->status & IPS_NAT_MASK && (ctinfo != IP_CT_RELATED || info->commit)) { /* NAT an established or related connection like before. */ if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY) /* This is the REPLY direction for a connection * for which NAT was applied in the forward * direction. Do the reverse NAT. */ maniptype = ct->status & IPS_SRC_NAT ? NF_NAT_MANIP_DST : NF_NAT_MANIP_SRC; else maniptype = ct->status & IPS_SRC_NAT ? NF_NAT_MANIP_SRC : NF_NAT_MANIP_DST; } else if (info->nat & OVS_CT_SRC_NAT) { maniptype = NF_NAT_MANIP_SRC; } else if (info->nat & OVS_CT_DST_NAT) { maniptype = NF_NAT_MANIP_DST; } else { return NF_ACCEPT; /* Connection is not NATed. */ } However, for bidirectional flow (IP_CT_ESTABLIED in conntrack term), the bare nat action will do nat directly and the second flow will not matched. My questions is whether this behavior is expected? or it is used to mimic the linux conntrack&nat behavior. I think if we can use bare nat to do nat for the unidirectional second and later packet, we can reduce a datapath flow and a upcall, which may seem boost performance a little better. Thanks a lot.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss