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.


Reply via email to