Hi, Larger inside address set require more heap size memory, see https://wiki.fd.io/view/VPP/NAT#Memory_requirements
Matus From: Hamid Rasool <14mseesras...@seecs.edu.pk> Sent: Tuesday, April 10, 2018 6:47 PM To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <matfa...@cisco.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP crash bug in CGNAT module Thanks Matus for clarification. We have fixed our configs accordingly, but as it was a bug that we encountered so I posted in the forum. A similar crash also occur sometimes using 'nat44 deterministic add in <addr>/<plen> out <addr>/<plen>' command as well. For cases in which subnet for inside address is set low (e.g. 16) and the outside subnet (e.g. 28), a similar crash is occured, without warning. vpp#nat44 deterministic add in 10.10.0.0/16<http://10.10.0.0/16> out 192.168.10.64/28<http://192.168.10.64/28> root@xflow:~# On Tue, Apr 10, 2018 at 7:09 PM, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <matfa...@cisco.com<mailto:matfa...@cisco.com>> wrote: Hi, When NAT plugin is running in deterministic mode you should use only CLI commands from list here https://wiki.fd.io/view/VPP/NAT#CLI_2 (for 1801 works only “show nat44” instead of all “show nat44 deterministic …” commands”) You should not use “nat44 add interface address” or “nat44 add address”. Currently there is no check for NAT plugin mode in CLI or API, so wrong commands may cause crash. I will fix this to avoid using of wrong configuration. Matus From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Hamid via Lists.Fd.Io<http://Lists.Fd.Io> Sent: Tuesday, April 10, 2018 3:55 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] VPP crash bug in CGNAT module Hi, I am using stable/1801 source build and have encountered a bug due to the CGNAT plugin. When using deterministic CGN and using the nat { deterministic } option in the startup.conf, if you apply normal nat44 rules, the interfaces do not work as expected. And by initiating a ping command, vppctl crashes and exits and with it, removes all its applied previous configuration from the CLI. Here is a sample setup (loop0 and loop1 have been configured): vpp# nat44 add interface address loop0 vpp# set interface nat44 in loop1 out loop0 vpp# nat44 add address 192.168.10.20 - 192.168.10.30 Now, when the ping command is run (IP address is of a tap interface initialized in vpp), vpp crashes and all CLI configuration resets: vpp# ping 192.168.100.2 root@xflow:~# When the 'nat { deterministic }' statement is removed from the startup conf, the issue is resolved and the setup behaves as intended.