Hi Matus, Thanks for your answers here.
On Sat, Feb 18, 2017 at 12:36 AM, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <matfa...@cisco.com> wrote: > If external_sw_if_index value is ~0 (-1) external_ip_address is ussed from > API (snat.c line 363). > OK, I see that in the code, but it is nowhere described in the API itself. That is my issue here. Magic values like this *are* part of the API as they will affect changes on the VPP-side of the API interface. > snat_add_address_range – add address range to SNAT address pool > > snat_add_del_interface_addr – add address of the interface to SNAT address > pool (address is added/removed automatically when interface address is > changed by configuration or DHCP) > So one could use either or both, as they wish? I guess I'm having a bit of hard time trying to figure out what the canonical API call sequence would be to set up various useful and standard NAT situations. Yes, I've read the Wiki page; No it isn't clear on the proper, expected sequence of the API calls. How does those API sequences change for the different values of the config variables "static_mapping_only" and "static_mapping_connection_tracking"? And on that note -- How do you change the value of those config varaibles at run time? I know how to alter the config file and re-read them in VAT. I'm not using VAT. I'm writing a totally different system. Can those values be changed at run-time? There is no API to do so, so at this point in time the answer must be "no." Is it expected that the sequence to change these configuration values at run time is to: 1) Stop VPP, 2) write a new config file with the new desired values, 3) restart VPP? That seems bad to me. I think 1024 is not significant, it's just a warning that you add a lot of > addresses to SNAT address pool, it was here before I started work on SNAT > plugin. > Well, 1024 is arbitrary. Who is to say that I don't need 2048 and don't care about the warning in my environment? To be clear, I'm not blaming you (Matus), or anyone for that matter. I'm merely pointing out that it is an arbitrary and undocumented limit in the current system. > Matus > Thanks, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
