We are seeing the below two issues with NAT in the VPP 18.01 stable release. Kindly resolve these bugs ASAP to facilitate a stable & functional VPP deployment.
 
Issue #1: A static NAT does not take precedence over the dynamic NAT sessions.
 
In VPP, it is required to clear a user's dynamic NAT sessions before a static NAT is added, so the static NAT could take precedence.
However, clearing all dynamic NAT sessions and adding a static NAT does not work when the VM is actively sending traffic.The dynamic NAT session is added right back in by VPP and it still takes precedence over the static NAT.
The correct behavior should be - A static 1:1 NAT should take precedence over any existing dynamic NAT sessions.
 
Issue #2: Incorrect protocol value in static NAT
When a static NAT session is added with the protocol=0, (i.e. all protocols), the static_mapping_dump incorrectly shows that the protocol field is set to 17 (UDP) only.
 
vpp.nat44_add_del_static_mapping(
    ....:     local_ip_address=local_ip,
    ....:     external_ip_address=external_ip,
    ....:     external_sw_if_index=0xFFFFFFFF,  # Unused
    ....:     local_port=0,     # 0 = ignore
    ....:     external_port=0,  # 0 = ignore
    ....:     addr_only=1,       # 1 = address only mapping
    ....:     vrf_id=0,          # 0 = global VRF
    ....:     is_add=1,          # 1 = add, 0 = del
    ....:     protocol=0
    ....:     )
 
In the dump for the above SNAT mapping, VPP sets the protocol value to 17 (UDP)
In [33]: vpp.nat44_static_mapping_dump()
Out[33]: [nat44_static_mapping_details(_0=790, context=13, addr_only=1, local_ip_address='\n\x01\x01\x04', external_ip_address='\xc0\xa8\xc8\n', protocol=17, local_port=0, external_port=0, external_sw_if_index=4294967295, vrf_id=0, twice_nat=0)]