Re: [vpp-dev] NAT44 for TCP/UDP

[filvarga]

Hi Ashwini,

I will look into your issue. But for reference I would advise against using
a combination of inside interface and output-feature.

OUTPUT-FEATURE or in other words output interface already contains
nat44-inside node. Output-feature does postrouting - after ip4-lookup node
decides which interface the packet is supposed to go to - in your config it
would be wan1 or wan2 then the translation occurs. Either use combination
of

nat44 in lan
nat44 out wan1
nat44 out wan2

or

nat44 out wan1 output-feature
nat44 out wan2 output-feature
.

The CLI is not very user friendly. Specifically in configuring
output-feature because it looks like you are actually configuring the
outside interface but you are not; instead the wan1 or wan2 contain both
nat44 inside (output-feature) and nat44 outside nodes.

I will do some testing and get back to you.

Best regards,
Filip Varga


ut 9. 8. 2022 o 2:49 Ashwini Kadam  napísal(a):

> Hi All,
>
>
>
> I am trying to make NAT44 ed work for TCP/UDP traffic on my setup. My
> setup is as follows
>
>
>
> Host A, Host B   <-VPP <-   Host C
>
>
>
> Host A , Host B and Host C can communicate to each other via VPP. The VPP
> container has two interfaces. My current version of VPP is 22.10 . The
> startup config is as follows
>
>
>
> unix {
>
> nodaemon
>
> log /var/log/vpp/vpp.log
>
> interactive
>
> full-coredump
>
> cli-listen /run/vpp/cli.sock
>
> poll-sleep-usec 100
>
> startup-config setup.tmpl
>
> gid vpp
>
>   }
>
>   api-trace { on }
>
>   api-segment { gid vpp }
>
>   socksvr { default }
>
>   dpdk {
>
>log-level debug
>
> dev default {
>
>   num-rx-desc 512
>
>   num-tx-desc 512
>
> }
>
> # Replace PCIDEVICE once Pod is up
>
> dev :07:13.2 {
>
>   name lan
>
> }
>
> dev :07:12.6 {
>
>   name wan1
>
> }
>
> dev :07:13.0 {
>
>   name wan2
>
> }
>
> uio-driver vfio-pci
>
>   }
>
>   cpu {}
>
>   memory {
>
> # main-heap-size 1G
>
> # main-heap-page-size 1G
>
> default-hugepage-size 1G
>
>   }
>
>   logging {
>
>  default-log-level debug
>
>  default-syslog-log-level debug
>
>   }
>
>
>
>   plugins {
>
>
>
> plugin dpdk_plugin.so { enable }
>
> plugin dhcp_plugin.so { enable }
>
> plugin nat_plugin.so { enable }
>
> plugin nat44_plugin.so { enable }
>
> plugin nat44_ei_plugin.so  { enable }
>
> plugin cnat_plugin.so { enable }
>
> plugin ping_plugin.so { enable }
>
> plugin det44_plugin.so { enable }
>
> plugin map_plugin.so { enable }
>
> plugin dns_plugin.so { enable }
>
> plugin tracedump_plugin.so { enable }
>
>   }
>
>
>
>
>
>
>
>
>
>
>
> VPP dpdk interface IP’s
>
>
>
> Lan : 192.168.1.x/24
>
> Wan1 :  10.x.x.x/24
>
> Wan2 : 10.x.x.x/24
>
>
>
> Host C has interface with IP : 192.168.1.20/24. Iperf3 is run on Host C
> as server and on Host A as a client
>
> My NAT configuration is as follows
>
>
>
>   nat44 plugin enable sessions 63000
>
>   nat44 forwarding enable
>
>   set nat timeout udp 300 tcp-established 7440 tcp-transitory 240 icmp 60
>
>   nat mss-clamping 1452
>
>   set interface nat44 in lan
>
>   set interface nat44 out wan1 output-feature
>
>   set interface nat44 out wan2 output-feature
>
>   nat44 add static mapping tcp local 192.168.1.20 external 4.4.4.4
>
>
>
>
>
> However when I look at my nat44 sessions I don’t see any re-writes
> happening. The rules don’t get applied. The same works for ICMP traffic but
> not for UDP or TCP . Also I see a lot of garbage data coming in. Below as
> an example of nat44 session I see for tcp traffic
>
>
>
> NAT44 ED sessions:
>
>  thread 0 vpp_main: 2 sessions 
>
> i2o 192.168.1.20 proto TCP port 5201 fib 0
>
> o2i 192.168.1.20 proto TCP port 5201 fib 0
>
>external host 10.197.61.30:33702
>
>i2o flow: match: saddr 192.168.1.20 sport 5201 daddr 10.197.61.30
> dport 33702 proto TCP fib_idx 0 rewrite: txfib 0
>
>o2i flow: match: saddr 0.0.0.0 sport 0 daddr 0.0.0.0 dport 0 proto
> IP6_HOP_BY_HOP_OPTIONS fib_idx 0
>
>index 0
>
>last heard 216.03
>
>timeout in 239.92
>
>total pkts 43, total bytes 2148
>
>dynamic translation
>
>forwarding-bypass
>
>
>
> i2o 192.168.1.20 proto TCP port 5201 fib 0
>
> o2i 192.168.1.20 proto TCP port 5201 fib 0
>
>external host 10.197.61.30:33704
>
>i2o flow: match: saddr 192.168.1.20 sport 5201 daddr 10.197.61.30
> dport 33704 proto TCP fib_idx 0 rewrite: txfib 0
>
>o2i flow: match: saddr 0.0.0.0 sport 0 daddr 0.0.0.0 dport 0 proto
> IP6_HOP_BY_HOP_OPTIONS fib_idx 0
>
>index 1
>
>last heard 215.95
>
>timeout in 239.83
>
>total pkts 5395516, total bytes 21042010
>
>dynamic translation
>
>forwarding-bypass
>
>
>
> Below is output of nat44 summary
>
>
>
> vpp# show nat44 summary
>
> max translations per thread: 63000 fib 0
>
> t

Re: [vpp-dev] NAT44 for TCP/UDP

[filvarga]

Hi Ashwini,

Can you also please send me a packet trace from VPP ?

Thank you.

Best regards,
Filip Varga


ut 9. 8. 2022 o 23:50 Ashwini Kadam  napísal(a):

> Hi Filip,
>
> I did try your recommendations . Updated NAT config to as below
>
> Test Case 1
> nat44 plugin enable sessions 63000
> nat44 forwarding enable
> set nat timeout udp 3000 tcp-established 7440 tcp-transitory 2400 icmp 600
> set interface nat44 in lan
> set interface nat44 out wan1
> set interface nat44 out wan2
> nat44 add static mapping tcp local 192.168.1.20 external 4.4.4.4
>
> Test Case 2
>
> nat44 plugin enable sessions 63000
> nat44 forwarding enable
> set nat timeout udp 3000 tcp-established 7440 tcp-transitory 2400 icmp 600
> set interface nat44 out wan1 output-feature
> set interface nat44 out wan2 output-feature
> nat44 add static mapping tcp local 192.168.1.20 external 4.4.4.4
>
>
>
> However in both cases i see the same result as below
>
> vpp# show nat44 sessions
> NAT44 ED sessions:
>  thread 0 vpp_main: 2 sessions 
> i2o 192.168.1.20 proto TCP port 5201 fib 0
> o2i 192.168.1.20 proto TCP port 5201 fib 0
>external host 10.197.61.30:42280
>i2o flow: match: saddr 192.168.1.20 sport 5201 daddr 10.197.61.30
> dport 42280 proto TCP fib_idx 0 rewrite: txfib 0
>o2i flow: match: saddr 0.0.0.0 sport 0 daddr 0.0.0.0 dport 0 proto
> IP6_HOP_BY_HOP_OPTIONS fib_idx 0
>index 0
>last heard 287.92
>timeout in 2396.83
>total pkts 30, total bytes 985
>dynamic translation
>forwarding-bypass
>
> i2o 192.168.1.20 proto TCP port 5201 fib 0
> o2i 192.168.1.20 proto TCP port 5201 fib 0
>external host 10.197.61.30:42284
>i2o flow: match: saddr 192.168.1.20 sport 5201 daddr 10.197.61.30
> dport 42284 proto TCP fib_idx 0 rewrite: txfib 0
>o2i flow: match: saddr 0.0.0.0 sport 0 daddr 0.0.0.0 dport 0 proto
> IP6_HOP_BY_HOP_OPTIONS fib_idx 0
>index 1
>last heard 287.84
>timeout in 2396.75
>total pkts 4720516, total bytes 5249440
>dynamic translation
>forwarding-bypass
>
> The other thing I noticed was the output says dynamic translations instead
> of static translations.
> In ICMP nat44 sessions i can see that it shows static translations. Below
> is an ICMP NAT44 session
>
> vpp# show nat44 sessions
> NAT44 ED sessions:
>  thread 0 vpp_main: 1 sessions 
> i2o 192.168.1.20 proto ICMP port 141 fib 0
> o2i 4.4.4.4 proto ICMP port 141 fib 0
>external host 10.197.61.30:141
>i2o flow: match: saddr 192.168.1.20 sport 141 daddr 10.197.61.30
> dport 141 proto ICMP fib_idx 0 rewrite: saddr 4.4.4.4 daddr 10.197.61.30
> icmp-id 141 txfib 0
>o2i flow: match: saddr 10.197.61.30 sport 141 daddr 4.4.4.4 dport
> 141 proto ICMP fib_idx 0 rewrite: daddr 192.168.1.20 icmp-id 141 txfib 0
>index 0
>last heard 127.02
>timeout in -26.69
>total pkts 40, total bytes 3360
>static translation
>
>
> Also have a couple of questions. MY VPP has 3 dpdk interfaces each for
> lan, wan1, wan2 . The lan interface IP is 192.168.1.1.
> In my static mapping i am creating a rule as below
>
> nat44 add static mapping tcp local 192.168.1.20 external 4.4.4.4
>
> While creating static mapping rules what should the local correspond to (
> here i am setting it to IP of Host C and not the VPP dpdk interface IP )
> and what should the external correspond to ( here i am setting it to a fake
> external IP and not wan1 or wan2 IP ).
>
> I aso tried to det44 nat however ran into the following issues.
>
> In startup config if i add the nat { deterministic } or just nat {} config
> it fails to run. Run into an error saying unkown nat configuration.
>
> Tried the below det44 nat however dint see any translations in sessions.
>
> det44 plugin enable
> set nat timeout udp 300 tcp-established 7440 tcp-transitory 240 icmp 6000
> set interface det44 inside lan outside wan
> det44 add in 192.168.1.0/24 out 4.4.4.0/24
>
> I see a deubg message saying and dont see any det44 sessions.
>
> vpp# det44   [info  ]: unknown dst address:  192.168.1.20
> det44[info  ]: unknown dst address:  192.168.1.20
> det44[info  ]: unknown dst address:  192.168.1.20
>
> Do let me know what I am missing. Is a different VPP version i should use
> ? My current one is build from master branch 22.10. Thanks
>
> Regards,
> Ashwini Kadam
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21785): https://lists.fd.io/g/vpp-dev/message/21785
Mute This Topic: https://lists.fd.io/mt/92906473/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] NAT44 for TCP/UDP

[filvarga]

Hi Ashwini,

Thank you. I am looking into it.

Best regards,
Filip Varga


po 15. 8. 2022 o 21:33 Ashwini Kadam  napísal(a):

> Hi Filip,
>
> Please let me know your thoughts on what the issue is and how it can be
> resolved. We are working towards a demo and hoping to use VPP in it. This
> is kind of a blocker right now.
>
> Regards,
> Ashwini Kadam
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21800): https://lists.fd.io/g/vpp-dev/message/21800
Mute This Topic: https://lists.fd.io/mt/92906473/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] nat44-ed distinct pool for out if

[filvarga]

Hi,

I would suggest checking vrf table implementation in NAT44-ED that enables
restriction of passing packets between different VRFs for more information
check commit 691c630b79ec2230b67944c8a9f77f95b49d95ad

Meanwhile I will look if there is something else to use. If I find
something I will respond back to you.

Best regards,
Filip Varga


st 21. 9. 2022 o 10:24 Ole Troan  napísal(a):

> Hi Amir,
>
> Have you tried configuring the NAT with “output-feature” enabled?
>
> Best regards,
> Ole
>
> > On 21 Sep 2022, at 06:43, Amir Hossein <1377amirhossein1...@gmail.com>
> wrote:
> >
> > 
> > Hi,
> > I'm working with nat44-ed plugin and I found that we can set a distinct
> nat ip pool for each in if (with tenant-vrf) and we can have multiple out
> if.
> > But is there a way to have a distinct nat ip pool for each out if?
> > Imagine a scenario in which  a host connects to two isps (with two if
> each with different nat ip), i can select outgoing interface,
> > but nat ip selection is based on rx interface(sth like a->fib_index ==
> rx_fib_index if i'm not mistaken).
> > How can I have a different nat ip pool for each out if?
> > Best regards,
> > amir.
> >
> >
> >
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21905): https://lists.fd.io/g/vpp-dev/message/21905
Mute This Topic: https://lists.fd.io/mt/93820447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] nat44-ed distinct pool for out if

[filvarga]

Hi Amir,

If I understand your use case correctly you have 2 inside and 2 outside
interfaces. 2 outside belong to two different ISPs. You want communication
entering inside interface one to go through let's say outside interface one
and vice versa for the other two.

inside 1 <-> outside 1
inside 2 <-> outside 2

So from here there are multiple possibilities on how to approach the
problem. It really comes to the point if you need to network from inside 1
reach network behind inside 2 or network from inside 1 to reach network
behind outside 2 and vice versa.

Solution a)
1. Create 2 vrfs
2. Put inside 1 and outside 1 to vrf 1
3. Put inside 2 and outside 2 to vrf 2
4. configure NAT
4.1 enable nat
4.2 configure 2 nat addresses for each outside interface:
`nat44 add interface address ...`
4.3 configure outside and inside nat44 interfaces:
`set interface nat44 in  out `
`set interface nat44 in  out `

- This should work out of the box. You have its own default gateway for
each vrf. NAT will pick up this fact and pass traffic through the vrf we
are in.

Solution nat vrf tables b)
Basically creating a vrf table for specific inside vrf  - this could be the
default one for example restricts nat ability to pass packets between vrfs.
If solution a) doesn't work you can create a nat vrf table for vrf 1 and
vrf 2. If you create a table without adding entries into it NAT inter VRF
passing of packets get's disabled.
So you basically restrict all NAT traffic inside one vrf.

Now if you need to reach some resources between vrfs you can start adding
entries to the table, the output vrf gets decided based on the first table
in the list resolving route.
So let's say:

nat vrf table for vrf1
first entry vrf1
second entry vrf2

internet traffic - reaching public space ip
inside 1 (vrf1) - > goes through (vrf1) because obviously vrf1 can resolve
the ip
private space traffic trying to reach ISPS private addresses (let's say
scenario where there is another router up the line - behind our outside
interface) reachable only through vrf2 outside 2 interface
inside 1 (vrf1) - > goes through (vrf2) because vrf1 wasn't able to resolve
the ip and vrf2 was.

The possibilities can get more and more complicated down the line. You can
for example configure the interface to be both inside and outside and make
NAT pass traffic using the above logic between inside ones in different vrs
and so on.

Best regards,
Filip Varga

št 22. 9. 2022 o 11:43 Amir Hossein <1377amirhossein1...@gmail.com>
napísal(a):

> Hi Filip,
> thanks for suggestion,
> so i can have a vrf(rx) use nat ip pool from another tenant vrf?
> I'm a little confused about using nat vrf routes can you give me an
> example?
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21912): https://lists.fd.io/g/vpp-dev/message/21912
Mute This Topic: https://lists.fd.io/mt/93820447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] NAT44 for TCP/UDP

[filvarga]

Hi Ashwini,

I am sorry I wasn't able to respond earlier.

Basically you have multiple issues here. You are not configuring NAT
outside address as suggested by yangbin. Though you can ignore the default
route comment you don't need to worry about this to make the example work.
Also output-feature (post routing) vs in and out  (similar to prerouting)
configuration commes basically down to the use case you have. Usually if
you have just one wan interface and you want to nat all the packets from
all of the other interfaces going outside of the wan interface but you
don't want any other communication internally (between local lan interface)
to be nated then you can stick with output-feature. Post and Pre routing as
mentioned before are just features of NAT that decide at what stage of
packet processing translation occurs.

What you have to do to make the setup work is pretty simple.

1) setup basic nat configuration - aka dynamic nat enabled

nat44 enable

set interface nat44 in lan

set interface nat44 out wan1
set interface nat44 out wan2

nat44 add interface address wan1
nat44 add interface address wan2

or:

nat44 enable

set interface nat44 out wan1 output-feature
set interface nat44 out wan2 output-feature

nat44 add interface address wan1
nat44 add interface address wan2

2) configure static mapping

nat44 add static mapping local 192.168.1.20 external 
or
nat44 add static mapping local 192.168.1.20 external 

NOTES:
- this is an address only type of  static mapping. I would rather suggest
configuring port mapping.
- using tcp in address only mapping has no use.

nat44 add static mapping tcp local 192.168.1.20  external
 
or
nat44 add static mapping tcp local 192.168.1.20  external
 

- nat44 ed requires nat44 pool address to be configured to use static
mapping
- you can configure nat44 pool address simply by running the command "nat44
add interface address wan1" or manually specifying the address "nat44 add
address 4.4.4.4"

This to work several conditions must be met:
a) vpp interface needs to be configured with ip address (for example
4.4.4.4)
b) nat44 outside interface has to be configured on the vpp interface with
4.4.4.4 address
c) nat44 ed plugin needs to have pool address (the same as the interface
4.4.4.4)

Example [0]:

set interface state lan up
set interface state wan1 up
set interface state wan2 up

set interface ip address lan 192.168.1.1/24
set interface ip address wan1 10.0.1.1/24
set interface ip address wan2 10.0.2.1/24

nat44 enable

set interface nat44 in lan
set interface nat44 out wan1
set interface nat44 out wan2

nat44 add address 10.0.1.1
nat44 add address 10.0.2.1

nat44 add static mapping tcp local 192.168.1.20 5001 external 10.0.1.1 5001

Because of NAT limitations we can't have multiple static mapping records
that share the same host and port.

Suggestion:
 1) if you don't have a specific need to change the default session
timeouts I would suggest against it
 2) if you don't know or need the forwarding feature don't use it.
  - with the forwarding feature on your dynamic translations won't work.
  - it is a special feature used in very rare situations

P.S.:
I would suggest using example[0] as the base of your configuration.
Obviously with updated IP addresses.

Hope I was able to help. Sorry again for the delay.

Best regards,
Filip Varga


st 21. 9. 2022 o 19:44 yangbin_1638136...@qq.com 
napísal(a):

> There are 2 types of NAT implementation.
> when you use "in" and "out" at same time. it's PRE-ROUTING NAT
> when you use "out" with "output-feature" keyword . it's POST-ROUTING NAT.
>
> no matter what type of NAT  you choose to use, there are 2 import thing
> you need to do,
> first,enable nat
> second,make sure you have a right NAT address pool.(nat44 add interface
> address {wan1} )
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21913): https://lists.fd.io/g/vpp-dev/message/21913
Mute This Topic: https://lists.fd.io/mt/92906473/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] testing vpp question

[filvarga]

Hi Laszlo,

Are you trying to run specifically the same tests as ones that are in
jenkins ?
You can simply install all requirements

make install-deps
make install-ext-deps

make test
or
make test-debug

I would also suggest running it in 22.04 ubuntu docker image.

Best regards,
Filip Varga


pi 23. 9. 2022 o 17:15 Laszlo Király  napísal(a):

> Hi,
> Could someone please advise me how to run vpp tests?
>
> I followed the instructions described in developer documentation
> https://s3-docs.fd.io/vpp/22.10/developer/build-run-debug/index.html
> I also checked the following Jenkins job configuration:
> https://jenkins.fd.io/job/vpp-verify-master-ubuntu2004-x86_64/configure
> Based on this I created a Dockerfile to build and test vpp on ubuntu 20.04:
>
> cat extras/docker/build/Dockerfile.ubuntu-20-04
> FROM ubuntu:20.04 as vppbuildandtest
> RUN apt-get update
> RUN DEBIAN_FRONTEND=noninteractive TZ=US/Central apt-get install -y git
> make python3 sudo asciidoc
> COPY . /vpp
> WORKDIR /vpp
> RUN curl -s
> https://packagecloud.io/install/repositories/fdio/${REPO}/script.deb.sh |
>  bash
> RUN apt-get update
> RUN apt-get -y --allow-downgrades --allow-remove-essential
> --allow-change-held-packages install vpp-ext-deps
> RUN DEBIAN_FRONTEND=noninteractive TZ=US/Central UNATTENDED=y make
> install-dep
> RUN make UNATTENDED=yes test-dep
> RUN make UNATTENDED=yes pkg-verify
> RUN src/tools/vppapigen/test_vppapigen.py
> RUN make UNATTENDED=yes test
>
> Until now I was able to run without errors, but the last several attempts
> failed with the failure:
>
>  Running setup.py develop for vpp-papi
> ERROR: Command errored out with exit status 1:
>  command: /usr/bin/python3 -c 'import sys, setuptools, tokenize;
> sys.argv[0] = '"'"'/vpp/src/vpp-api/python/setup.py'"'"';
> __file__='"'"'/vpp/src/vpp-api/python/setup.py'"'"';f=getattr(tokenize,
> '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))'
> develop --no-deps
>  cwd: /vpp/src/vpp-api/python/
> Complete output (17 lines):
> running develop
> error: can't create or remove files in install directory
>
> The following error occurred while trying to add or remove files in the
> installation directory:
>
> [Errno 2] No such file or directory:
> '/usr/lib/python3.8/site-packages/test-easy-install-112.write-test'
>
> Tried to fix the error adding the required directory
> '/usr/lib/python3.8/site-packages/', but other python modules missing.
> After installing 'psutil' and 'scapy' now facing another failure:
>
> make -C test VPP_BUILD_DIR=/vpp/build-root/build-vpp-native/vpp
> VPP_BIN=/vpp/build-root/install-vpp-native/vpp/bin/vpp
> VPP_INSTALL_PATH=/vpp/build-root/install-vpp-native/ EXTENDED_TESTS=
> PYTHON= OS_ID=ubuntu RND_SEED= CACHE_OUTPUT= TAG=vpp test
> make[1]: Entering directory '/vpp/test'
> Traceback (most recent call last):
>   File "/vpp/test/run_tests.py", line 17, in 
> from framework import (
>   File "/vpp/test/framework.py", line 35, in 
> from vpp_papi_provider import VppPapiProvider
>   File "/vpp/test/vpp_papi_provider.py", line 231, in 
> class VppPapiProvider(object):
>   File "/vpp/test/vpp_papi_provider.py", line 983, in VppPapiProvider
> protocol=socket.IPPROTO_RAW,
> NameError: name 'socket' is not defined
>
>
> /Laszlo
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21917): https://lists.fd.io/g/vpp-dev/message/21917
Mute This Topic: https://lists.fd.io/mt/93872230/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] nat44-ed distinct pool for out if

[filvarga]

"Using vrf routes and tables affect selected tx_fib_index but address
allocation for snat(nat_ed_alloc_addr_and_port function) is based on
rx_fib_index."
 - Pretty sure that's not true at all I would know as a maintainer of nat
:). If tx_fib_index is supplied then resolution of the pool address is
changed.

static int
nat_ed_alloc_addr_and_port (snat_main_t *sm, u32 rx_fib_index,
u32 tx_sw_if_index, u32 nat_proto,
u32 thread_index, ip4_address_t s_addr,
ip4_address_t d_addr, u32 snat_thread_index,
snat_session_t *s, ip4_address_t *outside_addr,
u16 *outside_port)
{
  if (vec_len (sm->addresses) > 0)
{
  u32 s_addr_offset = s_addr.as_u32 % vec_len (sm->addresses);
  snat_address_t *a, *ja = 0, *ra = 0, *ba = 0;
  int i;

  // output feature
  if (tx_sw_if_index != ~0)

 - here we go if tx_sw_if_index is supplied then resolution changes.
 - for both output & not output feature next line of code is used to grab
the tx_fib_index:

tx_fib_index = get_tx_fib_index (rx_fib_index, r_addr);

So I suggest playing around with the configuration. The hints I gave you
should direct you to correct configuration.

Best regards,
Filip Varga


so 24. 9. 2022 o 13:26 Amir Hossein <1377amirhossein1...@gmail.com>
napísal(a):

> thanks for your detail answer.
> but again my goal is to have separate nat ip pool per output interface.
> in my case i have one in interface and two out if, i want out if1 uses nat
> ip address A  and out if2 uses nat ip address B.
> using vrf routes and tables affect selected tx_fib_index but address
> allocation for snat(nat_ed_alloc_addr_and_port function) is based on
> rx_fib_index.
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21919): https://lists.fd.io/g/vpp-dev/message/21919
Mute This Topic: https://lists.fd.io/mt/93820447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] nat44-ed distinct pool for out if

[filvarga]

You are very welcome.

Best regards,
Filip Varga


st 28. 9. 2022 o 16:32 Amir Hossein <1377amirhossein1...@gmail.com>
napísal(a):

> Oh you're right.
> thanks to your guidance i was able to reach correct configuration.
> thanks a lot!
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21948): https://lists.fd.io/g/vpp-dev/message/21948
Mute This Topic: https://lists.fd.io/mt/93820447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

There are few errors in your statement.

1) SNAT - is an obsolete name for the old nat plugin.
2) NAT is split among multiple plugins
3) one of the plugins - nat44-ed (the most used and preferred) does support
all of the things you have mentioned

Please feel free to search in the community mailing list for configuration
examples. There is also .rst file in the nat44-ed plugin directory (may not
contain all of the supported configuration). Also check the api.c and cli.c
for all available configuration options.

After you have done above mentioned feel free to ask regarding specific
configuration issue.

Best regards,
Filip Varga


pi 21. 10. 2022 o 4:01 lihuawei  napísal(a):

> Hi John & Everyone & Community,
>
> In my scene, it is the demand to put multiple subnets in one BD. A few
> days ago, I have found the other proper idea to implement the demand mentioned
> in the mail subject and original mail.
>
> This problem and mail can be close now.
>
> Have a nice day, everybody!
>
>
> Thanks & Regards,
> Huawei LI
>
> 2022年10月21日 00:45，John Lo  写道：
>
> Hi Huawei,
>
> Some comments on supporting multiple BVIs in a BD:
>
> 1. There are assumptions in the bridging code including only 1 BVI per BD
> and it will be the last interface of a BD's flood list.  To support
> multiple BVIs per BD will make the code more complicated and less efficient
> from performance point of view.
>
> 2. All interfaces, including BVI, in a BD can talk to each other via MAC
> address learning.  There is no concept of L3 IP address nor awareness of
> IPs in separate VRFs. Thus, the concept of multiple BVIs in a BD each in
> different VRFs does not match the L2 bridging concept. While it may be
> possible to enhance BD support to understand IP and VRF at L3, it will
> again make the code more complicated and affect performance.
>
> My question would be, isn't it more natural to put each subnet in a
> separate BD with its BVI in the desired VRF?
>
> Regards,
> John
>
> -Original Message-
> From: lihuawei 
> Sent: Sunday, October 16, 2022 11:30 PM
> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale
> Ranns ; lojultra2...@outlook.com; slu...@cisco.com;
> vpp-dev@lists.fd.io
> Subject: snat support bind to specific subnets
>
> Hi Ole, Filip, Klement, Neale, John, Steven, &Community,
>
> I have a demand about snat. With in a vpc, different subnets  need use
> different snat ip to the internet, but the vpp snat feature now do not
> support snat ip bind to specific subnets. I have two ideas to resolve this:
> 1. modify and develop snat feature to support snat ip bind to specific
> subnets.
> 2. use multiple vrfs to isolate subnets, one vrf’s subnets use one snat
> ip, but the bd bvi now only support one in one bd, the non-bvi loop does
> not forward L3. So modify and develop bd bvi to support multiple bvi
> interfaces in one bd may be one better idea.
>
> Do I understand right and the idea 2 is the better? Anybody who has better
> idea, please help.
>
> Thanks and Regards,
> Huawei LI
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22079): https://lists.fd.io/g/vpp-dev/message/22079
Mute This Topic: https://lists.fd.io/mt/94377538/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

Yes, try to search one of my mail accounts (current/previous) for example
fiva...@cisco.com, filipvarg...@gmail.com or my name.
If you are looking for a feature that does ACL matching based on source
address you should try to look in different implementations of nat44, there
are more then one in vpp (one even supports acl matching).

Yes, the support for matching based on source subnet is not part of
nat44-ed and It would greatly change the current state for it. I wouldn't
suggest doing such a radical change. You can ofc. use as I mentioned
previously VRF logic. The only thing you need is 1 extra vrf to put one of
the inside interfaces into in conjunction with nat44 add address ...
tenant-vrf .

Regarding your problem with the bridge in VPP. You can go about using a
bridge in linux and connecting both interfaces in VPP to it. You would even
be able to have both VPP interfaces in the same subnet.

Best regards,
Filip Varga


št 27. 10. 2022 o 15:04 lihuawei  napísal(a):

> Hi Filip,
>
> Sorry, I didn’t state the demands clearly. My demand is to let a nat ip
> address just only work for specific src network prefix in a vpc, the nat
> sessions using the nat ip address will be created only when the i2o
> packets’s src ip matches the specific network prefix in the vpc.
> 1) I saw the snat_address_t’s member net is used only for matching the
> packets’s dst ip in nat_ed_alloc_addr_and_port.
> 2) using multiple vrfs to isolate the network is a method, but will use
> more other configures, and makes the traffic model more complex.
>
> By view the codes about nat44-ed, I don’t think there is any configuration
> examples about the demand I mentioned above. Do you have any keywords about
> the configuration examples? I want to try a search in mailing list with
> them.
>
> Do I understand this right? Looking forward to hearing any further ideas
> or suggestions from you.
>
> Thanks & Regards,
> Huawei LI
>
> 2022年10月27日 16:52，filvarga  写道：
>
> Hi Li,
>
> There are few errors in your statement.
>
> 1) SNAT - is an obsolete name for the old nat plugin.
> 2) NAT is split among multiple plugins
> 3) one of the plugins - nat44-ed (the most used and preferred) does
> support all of the things you have mentioned
>
> Please feel free to search in the community mailing list for configuration
> examples. There is also .rst file in the nat44-ed plugin directory (may not
> contain all of the supported configuration). Also check the api.c and cli.c
> for all available configuration options.
>
> After you have done above mentioned feel free to ask regarding specific
> configuration issue.
>
> Best regards,
> Filip Varga
>
>
> pi 21. 10. 2022 o 4:01 lihuawei  napísal(a):
>
>> Hi John & Everyone & Community,
>>
>> In my scene, it is the demand to put multiple subnets in one BD. A few
>> days ago, I have found the other proper idea to implement the demand 
>> mentioned
>> in the mail subject and original mail.
>>
>> This problem and mail can be close now.
>>
>> Have a nice day, everybody!
>>
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月21日 00:45，John Lo  写道：
>>
>> Hi Huawei,
>>
>> Some comments on supporting multiple BVIs in a BD:
>>
>> 1. There are assumptions in the bridging code including only 1 BVI per BD
>> and it will be the last interface of a BD's flood list.  To support
>> multiple BVIs per BD will make the code more complicated and less efficient
>> from performance point of view.
>>
>> 2. All interfaces, including BVI, in a BD can talk to each other via MAC
>> address learning.  There is no concept of L3 IP address nor awareness of
>> IPs in separate VRFs. Thus, the concept of multiple BVIs in a BD each in
>> different VRFs does not match the L2 bridging concept. While it may be
>> possible to enhance BD support to understand IP and VRF at L3, it will
>> again make the code more complicated and affect performance.
>>
>> My question would be, isn't it more natural to put each subnet in a
>> separate BD with its BVI in the desired VRF?
>>
>> Regards,
>> John
>>
>> -Original Message-
>> From: lihuawei 
>> Sent: Sunday, October 16, 2022 11:30 PM
>> To: o...@cisco.com; fiva...@cisco.com; klement.sek...@gmail.com; Neale
>> Ranns ; lojultra2...@outlook.com; slu...@cisco.com;
>> vpp-dev@lists.fd.io
>> Subject: snat support bind to specific subnets
>>
>> Hi Ole, Filip, Klement, Neale, John, Steven, &Community,
>>
>> I have a demand about snat. With in a vpc, different subnets  need use
>> different snat ip to the internet, but the vpp

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For
example PNAT uses ACL rules. You should go through all of the options there
are and pick the correct NAT flavor that will suffice.

Well your option is to do following:

1)

# lan1 interface belongs to vrf1
# lan2 interface belongs to vrf2
# wan0 interface belongs to default fib 0

set interface nat44 in lan1
set interface nat44 in lan2
set interface nat44 out wan0

nat44 add address <...address..> tenant-vrf 1
nat44 add address <...address..> tenant-vrf 2

2)

# lan1 and wan0 interfaces belong to default fib 0
# lan2 interface belongs to vrf1

--||--

nat44 add address <...address...>
nat44 add address <...address..> tenant-vrf 1

This is how you simply force the inside interface to use a specific NAT
pool address.

Best regards,
Filip Varga


št 27. 10. 2022 o 18:58 lihuawei  napísal(a):

> Hi Filip,
>
> I have searched your mail accounts, and didn’t find any acl configuration
> used with nat44. Do you mean use acl with nat44 address to achive to my
> target creating nat sessions based packet’s source ip's network?
>
> How about multi nat addresses respectively used for multi-subnets in a vrf?
>
> Thanks & Regards,
> Huawei LI
>
> 2022年10月27日 22:06，filvarga  写道：
>
> Hi Li,
>
> Yes, try to search one of my mail accounts (current/previous) for example
> fiva...@cisco.com, filipvarg...@gmail.com or my name.
> If you are looking for a feature that does ACL matching based on source
> address you should try to look in different implementations of nat44, there
> are more then one in vpp (one even supports acl matching).
>
> Yes, the support for matching based on source subnet is not part of
> nat44-ed and It would greatly change the current state for it. I wouldn't
> suggest doing such a radical change. You can ofc. use as I mentioned
> previously VRF logic. The only thing you need is 1 extra vrf to put one of
> the inside interfaces into in conjunction with nat44 add address ...
> tenant-vrf .
>
> Regarding your problem with the bridge in VPP. You can go about using a
> bridge in linux and connecting both interfaces in VPP to it. You would even
> be able to have both VPP interfaces in the same subnet.
>
> Best regards,
> Filip Varga
>
>
> št 27. 10. 2022 o 15:04 lihuawei  napísal(a):
>
>> Hi Filip,
>>
>> Sorry, I didn’t state the demands clearly. My demand is to let a nat ip
>> address just only work for specific src network prefix in a vpc, the nat
>> sessions using the nat ip address will be created only when the i2o
>> packets’s src ip matches the specific network prefix in the vpc.
>> 1) I saw the snat_address_t’s member net is used only for matching the
>> packets’s dst ip in nat_ed_alloc_addr_and_port.
>> 2) using multiple vrfs to isolate the network is a method, but will use
>> more other configures, and makes the traffic model more complex.
>>
>> By view the codes about nat44-ed, I don’t think there is any
>> configuration examples about the demand I mentioned above. Do you have any
>> keywords about the configuration examples? I want to try a search in
>> mailing list with them.
>>
>> Do I understand this right? Looking forward to hearing any further ideas
>> or suggestions from you.
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月27日 16:52，filvarga  写道：
>>
>> Hi Li,
>>
>> There are few errors in your statement.
>>
>> 1) SNAT - is an obsolete name for the old nat plugin.
>> 2) NAT is split among multiple plugins
>> 3) one of the plugins - nat44-ed (the most used and preferred) does
>> support all of the things you have mentioned
>>
>> Please feel free to search in the community mailing list for
>> configuration examples. There is also .rst file in the nat44-ed plugin
>> directory (may not contain all of the supported configuration). Also check
>> the api.c and cli.c for all available configuration options.
>>
>> After you have done above mentioned feel free to ask regarding specific
>> configuration issue.
>>
>> Best regards,
>> Filip Varga
>>
>>
>> pi 21. 10. 2022 o 4:01 lihuawei  napísal(a):
>>
>>> Hi John & Everyone & Community,
>>>
>>> In my scene, it is the demand to put multiple subnets in one BD. A few
>>> days ago, I have found the other proper idea to implement the demand 
>>> mentioned
>>> in the mail subject and original mail.
>>>
>>> This problem and mail can be close now.
>>>
>>> Have a nice day, everybody!
>>>
>>>
>>> Thanks & Regards,
>&g

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

What exactly do you mean by "new nat session rate limit" ? There is no
session rate limiting in the classical flavours of nat
(nat44-ed,nat44-ei,det44,nat64,nat66)

Best regards,
Filip Varga


pi 28. 10. 2022 o 3:09 lihuawei  napísal(a):

> Hi Filip,
>
> Thanks very much for your detailed instructions and configuration
> examples. I will try this method later on.
>
> Another question about nat, is there any support for new nat session rate
> limit in vpp?
>
>
> Thanks & Regards,
> Huawei LI
>
> 2022年10月28日 01:22，filvarga  写道：
>
> Hi Li,
>
> NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For
> example PNAT uses ACL rules. You should go through all of the options there
> are and pick the correct NAT flavor that will suffice.
>
> Well your option is to do following:
>
> 1)
>
> # lan1 interface belongs to vrf1
> # lan2 interface belongs to vrf2
> # wan0 interface belongs to default fib 0
>
> set interface nat44 in lan1
> set interface nat44 in lan2
> set interface nat44 out wan0
>
> nat44 add address <...address..> tenant-vrf 1
> nat44 add address <...address..> tenant-vrf 2
>
> 2)
>
> # lan1 and wan0 interfaces belong to default fib 0
> # lan2 interface belongs to vrf1
>
> --||--
>
> nat44 add address <...address...>
> nat44 add address <...address..> tenant-vrf 1
>
> This is how you simply force the inside interface to use a specific NAT
> pool address.
>
> Best regards,
> Filip Varga
>
>
> št 27. 10. 2022 o 18:58 lihuawei  napísal(a):
>
>> Hi Filip,
>>
>> I have searched your mail accounts, and didn’t find any acl configuration
>> used with nat44. Do you mean use acl with nat44 address to achive to my
>> target creating nat sessions based packet’s source ip's network?
>>
>> How about multi nat addresses respectively used for multi-subnets in a
>> vrf?
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月27日 22:06，filvarga  写道：
>>
>> Hi Li,
>>
>> Yes, try to search one of my mail accounts (current/previous) for example
>>  fiva...@cisco.com, filipvarg...@gmail.com or my name.
>> If you are looking for a feature that does ACL matching based on source
>> address you should try to look in different implementations of nat44, there
>> are more then one in vpp (one even supports acl matching).
>>
>> Yes, the support for matching based on source subnet is not part of
>> nat44-ed and It would greatly change the current state for it. I wouldn't
>> suggest doing such a radical change. You can ofc. use as I mentioned
>> previously VRF logic. The only thing you need is 1 extra vrf to put one of
>> the inside interfaces into in conjunction with nat44 add address ...
>> tenant-vrf .
>>
>> Regarding your problem with the bridge in VPP. You can go about using a
>> bridge in linux and connecting both interfaces in VPP to it. You would even
>> be able to have both VPP interfaces in the same subnet.
>>
>> Best regards,
>> Filip Varga
>>
>>
>> št 27. 10. 2022 o 15:04 lihuawei  napísal(a):
>>
>>> Hi Filip,
>>>
>>> Sorry, I didn’t state the demands clearly. My demand is to let a nat ip
>>> address just only work for specific src network prefix in a vpc, the nat
>>> sessions using the nat ip address will be created only when the i2o
>>> packets’s src ip matches the specific network prefix in the vpc.
>>> 1) I saw the snat_address_t’s member net is used only for matching the
>>> packets’s dst ip in nat_ed_alloc_addr_and_port.
>>> 2) using multiple vrfs to isolate the network is a method, but will use
>>> more other configures, and makes the traffic model more complex.
>>>
>>> By view the codes about nat44-ed, I don’t think there is any
>>> configuration examples about the demand I mentioned above. Do you have any
>>> keywords about the configuration examples? I want to try a search in
>>> mailing list with them.
>>>
>>> Do I understand this right? Looking forward to hearing any further
>>> ideas or suggestions from you.
>>>
>>> Thanks & Regards,
>>> Huawei LI
>>>
>>> 2022年10月27日 16:52，filvarga  写道：
>>>
>>> Hi Li,
>>>
>>> There are few errors in your statement.
>>>
>>> 1) SNAT - is an obsolete name for the old nat plugin.
>>> 2) NAT is split among multiple plugins
>>> 3) one of the plugins - nat44-ed (the most used and preferred) does
>>> support all of the things you have me

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi, Li

There is no such goal. It would’t be good idea to put rate limiting
directly into NAT. For many good reasons.

Much better solution would be to implement a new rate limiting plugin.

If you need such a functionality feel free to contribute.

Best regards

On Fri, 28 Oct 2022 at 18:35, lihuawei  wrote:

> Hi Filip,
>
> Yes, it’s "session rate limiting" what I mean.
>
> Does community have any plan about "session rate limiting" in the
> classical flavours of nat?
>
>
> Thanks & Regards,
> Huawei LI
>
> 2022年10月28日 21:20，filvarga  写道：
>
> Hi Li,
>
> What exactly do you mean by "new nat session rate limit" ? There is no
> session rate limiting in the classical flavours of nat
> (nat44-ed,nat44-ei,det44,nat64,nat66)
>
> Best regards,
> Filip Varga
>
>
> pi 28. 10. 2022 o 3:09 lihuawei  napísal(a):
>
>> Hi Filip,
>>
>> Thanks very much for your detailed instructions and configuration
>> examples. I will try this method later on.
>>
>> Another question about nat, is there any support for new nat session
>> rate limit in vpp?
>>
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月28日 01:22，filvarga  写道：
>>
>> Hi Li,
>>
>> NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For
>> example PNAT uses ACL rules. You should go through all of the options there
>> are and pick the correct NAT flavor that will suffice.
>>
>> Well your option is to do following:
>>
>> 1)
>>
>> # lan1 interface belongs to vrf1
>> # lan2 interface belongs to vrf2
>> # wan0 interface belongs to default fib 0
>>
>> set interface nat44 in lan1
>> set interface nat44 in lan2
>> set interface nat44 out wan0
>>
>> nat44 add address <...address..> tenant-vrf 1
>> nat44 add address <...address..> tenant-vrf 2
>>
>> 2)
>>
>> # lan1 and wan0 interfaces belong to default fib 0
>> # lan2 interface belongs to vrf1
>>
>> --||--
>>
>> nat44 add address <...address...>
>> nat44 add address <...address..> tenant-vrf 1
>>
>> This is how you simply force the inside interface to use a specific NAT
>> pool address.
>>
>> Best regards,
>> Filip Varga
>>
>>
>> št 27. 10. 2022 o 18:58 lihuawei  napísal(a):
>>
>>> Hi Filip,
>>>
>>> I have searched your mail accounts, and didn’t find any acl
>>> configuration used with nat44. Do you mean use acl with nat44 address to
>>> achive to my target creating nat sessions based packet’s source ip's
>>> network?
>>>
>>> How about multi nat addresses respectively used for multi-subnets in a
>>> vrf?
>>>
>>> Thanks & Regards,
>>> Huawei LI
>>>
>>> 2022年10月27日 22:06，filvarga  写道：
>>>
>>> Hi Li,
>>>
>>> Yes, try to search one of my mail accounts (current/previous) for example
>>>  fiva...@cisco.com, filipvarg...@gmail.com or my name.
>>> If you are looking for a feature that does ACL matching based on source
>>> address you should try to look in different implementations of nat44, there
>>> are more then one in vpp (one even supports acl matching).
>>>
>>> Yes, the support for matching based on source subnet is not part of
>>> nat44-ed and It would greatly change the current state for it. I wouldn't
>>> suggest doing such a radical change. You can ofc. use as I mentioned
>>> previously VRF logic. The only thing you need is 1 extra vrf to put one of
>>> the inside interfaces into in conjunction with nat44 add address ...
>>> tenant-vrf .
>>>
>>> Regarding your problem with the bridge in VPP. You can go about using a
>>> bridge in linux and connecting both interfaces in VPP to it. You would even
>>> be able to have both VPP interfaces in the same subnet.
>>>
>>> Best regards,
>>> Filip Varga
>>>
>>>
>>> št 27. 10. 2022 o 15:04 lihuawei  napísal(a):
>>>
>>>> Hi Filip,
>>>>
>>>> Sorry, I didn’t state the demands clearly. My demand is to let a nat ip
>>>> address just only work for specific src network prefix in a vpc, the nat
>>>> sessions using the nat ip address will be created only when the i2o
>>>> packets’s src ip matches the specific network prefix in the vpc.
>>>> 1) I saw the snat_address_t’s member net is used only for matching the
>>>> packets’s dst ip in nat_ed_alloc_addr_and_port.

[vpp-dev] gerrit GPG account issue

[filvarga]

Hi guys,

I was trying to set up a GPG signature for signing my commits. I followed
github guides [0] [1] that I used previously for setting up my github
account with GPG signing.

I face an issue when I try to add my exported public key into the New GPG
key gerrit field. Basically what happens is that I receive following error:

Error 400 (Bad Request): Problems with public key 8DC0D124 Filip Varga <
filipvarg...@gmail.com> (2423 8FAC 8EA1 571B 8799 0C96 6769 C6D2 8DC0
D124): Error checking user IDs for key Endpoint: /r/accounts/self/gpgkeys

I went through this process on my previous company account. I didn't face
this issue back then.

Export command used:
`gpg --armor --export`

Any help will be appreciated. Thank you in advance.

[0]
https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
[1]
https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key

Best regards,
Filip Varga

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22098): https://lists.fd.io/g/vpp-dev/message/22098
Mute This Topic: https://lists.fd.io/mt/94682179/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit Review Id 37559

[filvarga]

On it.

Best regards,
Filip Varga


po 31. 10. 2022 o 14:13 lihuawei  napísal(a):

> Hi community,
>
> I have added a fix as gerrit review id 37559.
>
> *gerrit link: https://gerrit.fd.io/r/c/vpp/+/37559
> *
>
> *short description: *Fix byte order error about the struct
> snat_address_t's member net. For example configurations:
> set interface ip table loop1 1
> set interface ip addr loop1 10.10.10.2/24
> nat44 add address 10.10.10.2 tenant-vrf 1
> The snat address's net should be "as_u8 = {0xa, 0xa, 0xa, 0x0}", but now
> it's "as_u8 = {0x0, 0xa, 0xa, 0x2}" because of missing transition of byte
> order about the member net of snat_address_t.
> (gdb) p/x *snat_main->addresses $3 = {addr = {data = {0xa, 0xa, 0xa, 0x2},
> data_u32 = 0x20a0a0a, as_u8 = {0xa, 0xa, 0xa, 0x2}, as_u16 = {0xa0a,
> 0x20a}, as_u32 = 0x20a0a0a}, net = {data = {0x0, 0xa, 0xa, 0x2}, data_u32 =
> 0x20a0a00, as_u8 = {0x0, 0xa, 0xa, 0x2}, as_u16 = {0xa00, 0x20a}, as_u32 =
> 0x20a0a00}, sw_if_index = 0x3, fib_index = 0x1,addr_len = 0x18}
> (gdb).
>
> Please have a look at my patch and review it.
>
> Best Regards,
> Huawei LI
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22100): https://lists.fd.io/g/vpp-dev/message/22100
Mute This Topic: https://lists.fd.io/mt/94684683/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

Glad to help.

Best regards,

Filip

On Mon, 31 Oct 2022 at 16:52, lihuawei  wrote:

> Hi Filip,
>
> I have tried to use extra vrf for routing the nat packets in my nat
> traffic scenario, it worked good, just caused a little bit of a problem
> and could be circumvented. I also tried the other way to add network
> prefix member in struct snat_address_t, it worked well too, and this method
> will simplify the traffic model and reduce vpp configuration in my
> scenario. I'll take it all into consideration, and chose the better one
> for me.
>
> Best regards,
> Huawei LI
>
> 2022年10月28日 01:22，filvarga  写道：
>
> Hi Li,
>
> NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For
> example PNAT uses ACL rules. You should go through all of the options there
> are and pick the correct NAT flavor that will suffice.
>
> Well your option is to do following:
>
> 1)
>
> # lan1 interface belongs to vrf1
> # lan2 interface belongs to vrf2
> # wan0 interface belongs to default fib 0
>
> set interface nat44 in lan1
> set interface nat44 in lan2
> set interface nat44 out wan0
>
> nat44 add address <...address..> tenant-vrf 1
> nat44 add address <...address..> tenant-vrf 2
>
> 2)
>
> # lan1 and wan0 interfaces belong to default fib 0
> # lan2 interface belongs to vrf1
>
> --||--
>
> nat44 add address <...address...>
> nat44 add address <...address..> tenant-vrf 1
>
> This is how you simply force the inside interface to use a specific NAT
> pool address.
>
> Best regards,
> Filip Varga
>
>
> št 27. 10. 2022 o 18:58 lihuawei  napísal(a):
>
>> Hi Filip,
>>
>> I have searched your mail accounts, and didn’t find any acl configuration
>> used with nat44. Do you mean use acl with nat44 address to achive to my
>> target creating nat sessions based packet’s source ip's network?
>>
>> How about multi nat addresses respectively used for multi-subnets in a
>> vrf?
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月27日 22:06，filvarga  写道：
>>
>> Hi Li,
>>
>> Yes, try to search one of my mail accounts (current/previous) for example
>>  fiva...@cisco.com, filipvarg...@gmail.com or my name.
>> If you are looking for a feature that does ACL matching based on source
>> address you should try to look in different implementations of nat44, there
>> are more then one in vpp (one even supports acl matching).
>>
>> Yes, the support for matching based on source subnet is not part of
>> nat44-ed and It would greatly change the current state for it. I wouldn't
>> suggest doing such a radical change. You can ofc. use as I mentioned
>> previously VRF logic. The only thing you need is 1 extra vrf to put one of
>> the inside interfaces into in conjunction with nat44 add address ...
>> tenant-vrf .
>>
>> Regarding your problem with the bridge in VPP. You can go about using a
>> bridge in linux and connecting both interfaces in VPP to it. You would even
>> be able to have both VPP interfaces in the same subnet.
>>
>> Best regards,
>> Filip Varga
>>
>>
>> št 27. 10. 2022 o 15:04 lihuawei  napísal(a):
>>
>>> Hi Filip,
>>>
>>> Sorry, I didn’t state the demands clearly. My demand is to let a nat ip
>>> address just only work for specific src network prefix in a vpc, the nat
>>> sessions using the nat ip address will be created only when the i2o
>>> packets’s src ip matches the specific network prefix in the vpc.
>>> 1) I saw the snat_address_t’s member net is used only for matching the
>>> packets’s dst ip in nat_ed_alloc_addr_and_port.
>>> 2) using multiple vrfs to isolate the network is a method, but will use
>>> more other configures, and makes the traffic model more complex.
>>>
>>> By view the codes about nat44-ed, I don’t think there is any
>>> configuration examples about the demand I mentioned above. Do you have any
>>> keywords about the configuration examples? I want to try a search in
>>> mailing list with them.
>>>
>>> Do I understand this right? Looking forward to hearing any further
>>> ideas or suggestions from you.
>>>
>>> Thanks & Regards,
>>> Huawei LI
>>>
>>> 2022年10月27日 16:52，filvarga  写道：
>>>
>>> Hi Li,
>>>
>>> There are few errors in your statement.
>>>
>>> 1) SNAT - is an obsolete name for the old nat plugin.
>>> 2) NAT is split among multiple plugins
>>> 3) one of the plugins - nat44-ed (the most use

Re: [vpp-dev] snat support bind to specific subnets

[filvarga]

Hi Li,

I would suggest looking into session logic implementation of NAT44-ED and
also into ACLs in VPP. The way to go would be to create a plugin that has
late limiting nodes.
Now you have two options on how to rate limit:

1) based on interface(s) - the more straightforward and easy to implement
solution.
 - enable nodes with vnet_feature_enable_disable on specific interfaces
 - hold a hash / pool that defines interface / interface combination that
should be rate limited
   - hold counters
   - consider how to effectively share values between threads (atomic
operations etc.)

2) based on network(s)
 - the same enable nodes as mentioned in 1)
 - now decide if the precedence is interface or ACL, or just use two
different types of rate limiting that shouldn't be used together
 - use VPP ACL implementation to create rules that need to be checked
 - again some pool that holds the data and ACL / hash returns an index to
the pool with the data.

As rate limiting rules are configuration options and not sessions like in
nat you wouldn't need to have per thread data. Creating hash records or
whatever you decide to use
would be done only through API/CLI which are thread safe operations. Then
just stick with atomics on the values.

The last part is for you to decide / implement some type of algo that
decides if the packet should be passed or dropped. This can be a little bit
tricky because of the VPPs batch processing or in other words how the
vector of packets is processed instead of per packet.

I would really advise you not to try to extend NAT with this functionality.
Separate plugin is a better solution.

I could look into this in my free time - if I have enough of it. Feel free
to pass any notes / ideas.

Best regards,
Filip Varga


po 31. 10. 2022 o 16:56 lihuawei  napísal(a):

> Hi Filip & community,
>
> About the rate limiting with NAT session, does anyone have recommended
>  reference?
>
> Best regards,
> Huawei LI
>
> 2022年10月29日 04:14，filvarga  写道：
>
> Hi, Li
>
> There is no such goal. It would’t be good idea to put rate limiting
> directly into NAT. For many good reasons.
>
> Much better solution would be to implement a new rate limiting plugin.
>
> If you need such a functionality feel free to contribute.
>
> Best regards
>
> On Fri, 28 Oct 2022 at 18:35, lihuawei  wrote:
>
>> Hi Filip,
>>
>> Yes, it’s "session rate limiting" what I mean.
>>
>> Does community have any plan about "session rate limiting" in the
>> classical flavours of nat?
>>
>>
>> Thanks & Regards,
>> Huawei LI
>>
>> 2022年10月28日 21:20，filvarga  写道：
>>
>> Hi Li,
>>
>> What exactly do you mean by "new nat session rate limit" ? There is no
>> session rate limiting in the classical flavours of nat
>> (nat44-ed,nat44-ei,det44,nat64,nat66)
>>
>> Best regards,
>> Filip Varga
>>
>>
>> pi 28. 10. 2022 o 3:09 lihuawei  napísal(a):
>>
>>> Hi Filip,
>>>
>>> Thanks very much for your detailed instructions and configuration
>>> examples. I will try this method later on.
>>>
>>> Another question about nat, is there any support for new nat session
>>> rate limit in vpp?
>>>
>>>
>>> Thanks & Regards,
>>> Huawei LI
>>>
>>> 2022年10月28日 01:22，filvarga  写道：
>>>
>>> Hi Li,
>>>
>>> NAT44-ED doesn't support ACL. There are other NAT plugins in VPP. For
>>> example PNAT uses ACL rules. You should go through all of the options there
>>> are and pick the correct NAT flavor that will suffice.
>>>
>>> Well your option is to do following:
>>>
>>> 1)
>>>
>>> # lan1 interface belongs to vrf1
>>> # lan2 interface belongs to vrf2
>>> # wan0 interface belongs to default fib 0
>>>
>>> set interface nat44 in lan1
>>> set interface nat44 in lan2
>>> set interface nat44 out wan0
>>>
>>> nat44 add address <...address..> tenant-vrf 1
>>> nat44 add address <...address..> tenant-vrf 2
>>>
>>> 2)
>>>
>>> # lan1 and wan0 interfaces belong to default fib 0
>>> # lan2 interface belongs to vrf1
>>>
>>> --||--
>>>
>>> nat44 add address <...address...>
>>> nat44 add address <...address..> tenant-vrf 1
>>>
>>> This is how you simply force the inside interface to use a specific NAT
>>> pool address.
>>>
>>> Best regards,
>>> Filip Varga
>>>
>>>
>>> št 27. 10. 2022 o 18:58 lihuawei  napísal(a):
>>>
>>>

Re: [vpp-dev] MAP-E Configuration

[filvarga]

Hi Ameen,

I will look into it and let you know.

Best regards,
Filip Varga


so 5. 11. 2022 o 13:13 Ameen Al-Azzawi  napísal(a):

> Hello Filip,
>
> I saw your reply to one of the MAP-related topics.
>
>
> I am trying to build the topology of MAP-E and MAP-T IPv6 transition
> technology.
>
> I am starting with MAP-E (IETF RFC- 7597).
>
>
>
> Please see attached pic of my Topology.
>
> I am trying to build “MAP-CE” and “MAP-BR” machines using VPP.
>
> Is It possible?
>
> On both MAP-CE and MAP-BR machines, I have successfully installed VPP
> (v20.09)
>
> All machines are CentOS-7 VMs.
>
> On MAP-CE machine, I have used below startup configuration: -
>
>
>
> unix {
>
> nodaemon
>
> log /var/log/vpp/vpp.log
>
> interactive
>
> full-coredump
>
> cli-listen /run/vpp/cli.sock
>
> poll-sleep-usec 100
>
> startup-config setup.tmpl
>
> gid vpp
>
>   }
>
>   api-trace { on }
>
>   api-segment { gid vpp }
>
>   socksvr { default }
>
>   dpdk {
>
>log-level debug
>
> dev default {
>
>   num-rx-desc 512
>
>   num-tx-desc 512
>
> }
>
>
>
> dev :07:12.6 {
>
>   name ens34
>
> }
>
> dev :07:13.0 {
>
>   name ens35
>
> }
>
> uio-driver vfio-pci
>
>   }
>
>   cpu {}
>
> #  memory {
>
> # main-heap-size 1G
>
> # main-heap-page-size 1G
>
>   #  default-hugepage-size 1G
>
>  # }
>
>   logging {
>
>  default-log-level debug
>
>  default-syslog-log-level debug
>
>   }
>
>
>
>   plugins {
>
> plugin dpdk_plugin.so { enable }
>
> plugin dhcp_plugin.so { enable }
>
> plugin nat_plugin.so { enable }
>
> plugin nat44_plugin.so { enable }
>
> plugin nat44_ei_plugin.so  { enable }
>
> plugin cnat_plugin.so { enable }
>
> plugin ping_plugin.so { enable }
>
> plugin det44_plugin.so { enable }
>
> plugin map_plugin.so { enable }
>
> plugin dns_plugin.so { enable }
>
> plugin tracedump_plugin.so { enable }
>
>   }
>
>
>
>
>
>  As for networking commands, I intend to use the followings: -
>
> nat44 plugin enable sessions 63000
>
> nat44 forwarding enable
>
> set nat timeout udp 3000 tcp-established 7440 tcp-transitory 2400 icmp 600
>
> set interface nat44 out  ens35 output-feature
>
> nat44 add static mapping tcp local 10.0.0.2 5000 external 203.0.113.1 1050
>
> nat44 add interface address ens35
>
>
> However, inside VPP (I mean after entering vppctl)
>
> I got the error below: -
>
>
>
> vpp# nat44 enable
>
> nat44: unknown input `enable'
>
> --
>
> How can I add the tunneling commands to my configuration so that MAP-CE
> functions as NAT44 + encapsulator.
>
> Last question, instead of static mapping, can I implement dynamic mapping?
>
> What is missing?
>
>
>
> Kind Regards
>
> Ameen
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22133): https://lists.fd.io/g/vpp-dev/message/22133
Mute This Topic: https://lists.fd.io/mt/94825188/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit Review Id 37579

[filvarga]

Hi,

That was already done. Please check your status.

Best regards,
Filip Varga


po 7. 11. 2022 o 9:01 lihuawei  napísal(a):

> Hi everyone,
>
> I have added a fix as gerrit review id 37579.
>
> *gerrit link: https://gerrit.fd.io/r/c/vpp/+/37579
> *
>
> *short description: *cli show policer's help info is not consistent with
> it's arguments.
>
> Please have a look and review.
>
> Best regards,
> Huawei LI
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22144): https://lists.fd.io/g/vpp-dev/message/22144
Mute This Topic: https://lists.fd.io/mt/94861307/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP Stateful NAT64 crashes with segmentation fault

[filvarga]

Hi Gabor,

I will look into it and get back to you. Meanwhile could you run the same
test with a debug build and post the results ? Maybe even core dump. Also
please post your startup.conf file

Best regards,
Filip Varga


st 9. 11. 2022 o 7:50 Gabor LENCSE  napísal(a):

> Dear VPP Developers,
>
> I am a researcher and I would like to benchmark the performance of the
> stateful NAT64 implementation of FD.io VPP.
>
> Unfortunately, VPP crashed with segmentation fault.
>
> Some details:
>
> I used two Dell PowerEdge R430 servers as the Tester and the DUT (Device
> Under Test), two 10GbE interfaces of which were interconnected by direct
> cables. On the DUT, I used Debian Linux 10.13 with 4.19.0-20-amd64 kernel
> and the version of FD.io VPP was 22.06. The following packages were
> installed: libvppinfra, vpp, vpp-plugin-core, vpp-plugin-dpdk.
>
> I used the following commands to set up Stateful NAT64:
>
> root@p109:~/DUT-settings# cat set-vpp
> vppctl set interface state TenGigabitEthernet5/0/0 up
> vppctl set interface state TenGigabitEthernet5/0/1 up
> vppctl set interface ip address TenGigabitEthernet5/0/0 2001:2::1/64
> vppctl set interface ip address TenGigabitEthernet5/0/1 198.19.0.1/24
> vppctl ip route add 2001:2::/64 via 2001:2::1 TenGigabitEthernet5/0/0
> vppctl ip route add 198.19.0.0/24 via 198.19.0.1 TenGigabitEthernet5/0/1
> vppctl set ip neighbor static TenGigabitEthernet5/0/0 2001:2::2
> a0:36:9f:74:73:64
> vppctl set ip neighbor static TenGigabitEthernet5/0/1 198.19.0.2
> a0:36:9f:74:73:66
> vppctl set interface nat64 in TenGigabitEthernet5/0/0
> vppctl set interface nat64 out TenGigabitEthernet5/0/1
> vppctl nat64 add prefix 64:ff9b::/96
> vppctl nat64 add pool address 198.19.0.1
>
> As for VPP, first I used two workers, but then I also tried without
> workers, using only the main core. Unfortunately, VPP crashed in both
> cases, but with somewhat different messages in the syslog. (Previously I
> tested both setups with IPv6 packet forwarding and they worked with an
> excellent performance.)
>
> The error messages in the syslog when I used two workers:
>
> Nov  7 16:32:02 p109 vnet[2479]: received signal SIGSEGV, PC
> 0x7fa86f138168, faulting address 0x4f8
> Nov  7 16:32:02 p109 vnet[2479]: #0  0x7fa8b2158137 0x7fa8b2158137
> Nov  7 16:32:02 p109 vnet[2479]: #1  0x7fa8b2086730 0x7fa8b2086730
> Nov  7 16:32:02 p109 vnet[2479]: #2  0x7fa86f138168 0x7fa86f138168
> Nov  7 16:32:02 p109 vnet[2479]: #3  0x7fa86f11d228 0x7fa86f11d228
> Nov  7 16:32:02 p109 vnet[2479]: #4  0x7fa8b20fbe62 0x7fa8b20fbe62
> Nov  7 16:32:02 p109 vnet[2479]: #5  0x7fa8b20fda4f vlib_worker_loop +
> 0x5ff
> Nov  7 16:32:02 p109 vnet[2479]: #6  0x7fa8b2135e79
> vlib_worker_thread_fn + 0xa9
> Nov  7 16:32:02 p109 vnet[2479]: #7  0x7fa8b2135290
> vlib_worker_thread_bootstrap_fn + 0x50
> Nov  7 16:32:02 p109 vnet[2479]: #8  0x7fa8b207bfa3 start_thread + 0xf3
> Nov  7 16:32:02 p109 vnet[2479]: #9  0x7fa8b1d75eff clone + 0x3f
> Nov  7 16:32:02 p109 systemd[1]: vpp.service: Main process exited,
> code=killed, status=6/ABRT
>
> The error messages in the syslog when I used only the main core:
>
> Nov  7 16:48:57 p109 vnet[2606]: received signal SIGSEGV, PC
> 0x7fbe1d24a168, faulting address 0x1a8
> Nov  7 16:48:57 p109 vnet[2606]: #0  0x7fbe6026a137 0x7fbe6026a137
> Nov  7 16:48:57 p109 vnet[2606]: #1  0x7fbe60198730 0x7fbe60198730
> Nov  7 16:48:57 p109 vnet[2606]: #2  0x7fbe1d24a168 0x7fbe1d24a168
> Nov  7 16:48:57 p109 vnet[2606]: #3  0x7fbe1d22f228 0x7fbe1d22f228
> Nov  7 16:48:57 p109 vnet[2606]: #4  0x7fbe6020de62 0x7fbe6020de62
> Nov  7 16:48:57 p109 vnet[2606]: #5  0x7fbe602127d1 vlib_main + 0xd41
> Nov  7 16:48:57 p109 vnet[2606]: #6  0x7fbe6026906a 0x7fbe6026906a
> Nov  7 16:48:57 p109 vnet[2606]: #7  0x7fbe60169964 0x7fbe60169964
> Nov  7 16:48:57 p109 systemd[1]: vpp.service: Main process exited,
> code=killed, status=6/ABRT
>
> As for the first time I started with quite high load, I suspected that I
> exhausted some sort of resources, so I tried with much lower load, but the
> same thing happened even when I sent only a single packet.
>
> I used siitperf as Tester: https://github.com/lencsegabor/siitperf
>
> And I followed this methodology:
> https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-benchmarking-stateful
>
> Previously my tests were successful with the following stateful NAT64
> implementations:
> - Jool
> - tayga+iptables
> - OpenBSD PF
>
> Could you please help me why VPP crashes, and how I could make it work?
>
> Thank you very much for your help in advance!
>
> Best regards,
>
> Gábor Lencse
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22154): https://lists.fd.io/g/vpp-dev/message/22154
Mute This Topic: https://lists.fd.io/mt/94908130/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@

[vpp-dev] email address update

[filvarga]

Hi guys,

Anyone willing to merge my maintainer address update patch ?
https://gerrit.fd.io/r/c/vpp/+/37581

Thank you.

Best regards,
Filip Varga

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22161): https://lists.fd.io/g/vpp-dev/message/22161
Mute This Topic: https://lists.fd.io/mt/94938635/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] email address update

[filvarga]

Thank you!

Best regards,
Filip Varga


št 10. 11. 2022 o 17:12 Andrew Yourtchenko  napísal(a):

> Done!
>
> --a
>
> On 10 Nov 2022, at 16:49, filvarga  wrote:
>
> 
> Hi guys,
>
> Anyone willing to merge my maintainer address update patch ?
> https://gerrit.fd.io/r/c/vpp/+/37581
>
> Thank you.
>
> Best regards,
> Filip Varga
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22163): https://lists.fd.io/g/vpp-dev/message/22163
Mute This Topic: https://lists.fd.io/mt/94938635/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MAP-E Configuration

[filvarga]

Hi Ameen

Please read first ./src/plugins/nat/nat44-ed/nat44_ed_doc.rst

Yes, running `nat44 enable` will fail because the correct command as you
have copy-pasted in your email is `nat44 plugin enable`. Also please avoid
using `nat44 forwarding enable`
if you are not sure what it exactly does in nat44-ed implementation. Please
read the docs first.

That being said, now about the map, the map is implemented in its own
plugin and it isn't part of NAT44-ED. So basically if I understand
correctly you are trying to pass communication through the IPv6 network. Do
you specifically need map-e to cowork with nat or could you use a different
solution to translate over 66 (have a look into nat66/nat64). Long time ago
there was support for olderver versions of nat plugin to cowork with MAP
implementation in VPP. I am pretty sure the NAT44-EI plugin at least
maintains some part of the functionality.

I can't say though how nat44-ed integrates with MAP nowadays. It would
require testing.

You can configure port allocation in nat44-ei that "limits for MAP-E CE
port choice based on PSID".
`vpp# nat44 ei addr-port-assignment-alg map-e psid 10 psid-offset 6
psid-len`

Also refer to https://wiki.fd.io/view/VPP/NAT oudtated docs!  Be aware that
functionality of the old obsolete plugin called SNAT was divided into
separate plugins. So information in the doc that mentions NAT44 / NAT64
etc. is referring to SNAT features which nowadays are their own plugins
contained in their respective sub folders of src/plugins/nat .

I would encourage you to test it with both nat44-ed and nat44-ei plugins.
If there are any nat configuration/translation related issues I will gladly
help.

Best regards,
Filip Varga


ne 6. 11. 2022 o 21:24 Ameen Al-Azzawi  napísal(a):

> Hallo Filip,
>
>
>
> Thanks in advance for your cooperation.
>
> Just a heads up.
>
> I have installed it again on ubuntu 22.04 (coz it has better support with
> VPP apparently).
>
> I have VPP version 22.10 here.
>
> I found VPP documentation regarding MAP-E and MAP-T: -
>
> https://wiki.fd.io/view/VPP/Configure_an_LW46_(MAP-E)_Terminator
>
>
>
> The question is, Is VPP used only as MAP-BR router? or also as MAP-CE?
>
>  And how to configure it? Coz the Dooku is not very clear honestly.
>
>
> Take your time and good night :)
>
>
> Regards
>
> Ameen
>
> On Sat, Nov 5, 2022 at 10:28 PM Filip Varga 
> wrote:
>
>> Hi Ameen,
>>
>> I will look into it and let you know.
>>
>> Best regards,
>> Filip Varga
>>
>>
>> so 5. 11. 2022 o 13:13 Ameen Al-Azzawi 
>> napísal(a):
>>
>>> Hello Filip,
>>>
>>> I saw your reply to one of the MAP-related topics.
>>>
>>>
>>> I am trying to build the topology of MAP-E and MAP-T IPv6 transition
>>> technology.
>>>
>>> I am starting with MAP-E (IETF RFC- 7597).
>>>
>>>
>>>
>>> Please see attached pic of my Topology.
>>>
>>> I am trying to build “MAP-CE” and “MAP-BR” machines using VPP.
>>>
>>> Is It possible?
>>>
>>> On both MAP-CE and MAP-BR machines, I have successfully installed VPP
>>> (v20.09)
>>>
>>> All machines are CentOS-7 VMs.
>>>
>>> On MAP-CE machine, I have used below startup configuration: -
>>>
>>>
>>>
>>> unix {
>>>
>>> nodaemon
>>>
>>> log /var/log/vpp/vpp.log
>>>
>>> interactive
>>>
>>> full-coredump
>>>
>>> cli-listen /run/vpp/cli.sock
>>>
>>> poll-sleep-usec 100
>>>
>>> startup-config setup.tmpl
>>>
>>> gid vpp
>>>
>>>   }
>>>
>>>   api-trace { on }
>>>
>>>   api-segment { gid vpp }
>>>
>>>   socksvr { default }
>>>
>>>   dpdk {
>>>
>>>log-level debug
>>>
>>> dev default {
>>>
>>>   num-rx-desc 512
>>>
>>>   num-tx-desc 512
>>>
>>> }
>>>
>>>
>>>
>>> dev :07:12.6 {
>>>
>>>   name ens34
>>>
>>> }
>>>
>>> dev :07:13.0 {
>>>
>>>   name ens35
>>>
>>> }
>>>
>>> uio-driver vfio-pci
>>>
>>>   }
>>>
>>>   cpu {}
>>>
>>> #  memory {
>>>
>>> # main-heap-size 1G
>>>
>>> # main-heap-page-size 1G
>>>
>>>   #  default-hugepage-size 1G
>>>
>>>  # }
>>>
>>>   logging {
>>>
>>>  default-log-level debug
>>>
>>>  default-syslog-log-level debug
>>>
>>>   }
>>>
>>>
>>>
>>>   plugins {
>>>
>>> plugin dpdk_plugin.so { enable }
>>>
>>> plugin dhcp_plugin.so { enable }
>>>
>>> plugin nat_plugin.so { enable }
>>>
>>> plugin nat44_plugin.so { enable }
>>>
>>> plugin nat44_ei_plugin.so  { enable }
>>>
>>> plugin cnat_plugin.so { enable }
>>>
>>> plugin ping_plugin.so { enable }
>>>
>>> plugin det44_plugin.so { enable }
>>>
>>> plugin map_plugin.so { enable }
>>>
>>> plugin dns_plugin.so { enable }
>>>
>>> plugin tracedump_plugin.so { enable }
>>>
>>>   }
>>>
>>>
>>>
>>>
>>>
>>>  As for networking commands, I intend to use the followings: -
>>>
>>> nat44 plugin enable sessions 63000
>>>
>>> nat44 forwarding enable
>>>
>>> set nat timeout udp 3000 tcp-established 7440 tcp-transitory 2400 icmp
>>> 600
>>>
>>> set interface nat44 out  ens35 output-feature
>>>
>>> nat44 add static mapping tcp local 10.0.0.2 5000 external 20

Re: [vpp-dev] VPP Stateful NAT64 crashes with segmentation fault

[filvarga]

Hi Gabor,

I would suggest using ubuntu 20.04 to build your .deb packages and then
upload them to the servers.
Basically you would do this:

1) git clone https://github.com/FDio/vpp.git && cd vpp
2) git checkout v22.06
3) make install-ext-dep
4) make install-dep
5) make pkg-deb-debug

Copy all of the .deb packages from the ./build-root directory to your
server and install them manually with dpkg.

The easiest way for me to figure out the issue would be for you to just
attach with gdb to vpp running single-worker.
1) sudo gdb --pid=$(pidof vpp)
2) Then just hit c so VPP continues to run
3) Simulate what caused the crash
4) in the gdb execute `bt`

And just send me the result of running bt.

But if it is too much you could also configure core dumps and upload so I
can check it for you.

Best regards,
Filip Varga


st 9. 11. 2022 o 8:37 Gabor LENCSE  napísal(a):

> Dear Filip,
>
> Thank you very much for your prompt reply!
>
> I have attached the startup.conf files for the case with 2 workers
> (startup.conf-mc1wc02) and for the case when I used only the main core
> (startup.conf-mc0). In both cases, 4 CPU cores (0-3) were enabled and cores
> 0-2 were excluded from the Linux scheduler using the "maxcpus=4" and
> "isolcpus=0-2" kernel command line parameters, respectively.
>
> I am new to FD.io VPP. Could you please advise me if there are pre-built
> debug packages available for Debian 10, and if yes, where can I find them?
>
> If I need to compile them myself, could you please give me a pointer, how
> I can do  it?
>
> I am currently using servers in NICT StarBED, Japan. This is a test-bed
> environment, and I can download packages only using a http or ftp proxy.
> (Or I can download them on my Windows laptop and upload them through a
> gateway.)
>
> Thank you very much in advance!
>
> Best regards,
>
> Gábor
> On 11/9/2022 4:04 PM, filvarga wrote:
>
> Hi Gabor,
>
> I will look into it and get back to you. Meanwhile could you run the same
> test with a debug build and post the results ? Maybe even core dump. Also
> please post your startup.conf file
>
> Best regards,
> Filip Varga
>
>
> st 9. 11. 2022 o 7:50 Gabor LENCSE  napísal(a):
>
>> Dear VPP Developers,
>>
>> I am a researcher and I would like to benchmark the performance of the
>> stateful NAT64 implementation of FD.io VPP.
>>
>> Unfortunately, VPP crashed with segmentation fault.
>>
>> Some details:
>>
>> I used two Dell PowerEdge R430 servers as the Tester and the DUT (Device
>> Under Test), two 10GbE interfaces of which were interconnected by direct
>> cables. On the DUT, I used Debian Linux 10.13 with 4.19.0-20-amd64 kernel
>> and the version of FD.io VPP was 22.06. The following packages were
>> installed: libvppinfra, vpp, vpp-plugin-core, vpp-plugin-dpdk.
>>
>> I used the following commands to set up Stateful NAT64:
>>
>> root@p109:~/DUT-settings# cat set-vpp
>> vppctl set interface state TenGigabitEthernet5/0/0 up
>> vppctl set interface state TenGigabitEthernet5/0/1 up
>> vppctl set interface ip address TenGigabitEthernet5/0/0 2001:2::1/64
>> vppctl set interface ip address TenGigabitEthernet5/0/1 198.19.0.1/24
>> vppctl ip route add 2001:2::/64 via 2001:2::1 TenGigabitEthernet5/0/0
>> vppctl ip route add 198.19.0.0/24 via 198.19.0.1 TenGigabitEthernet5/0/1
>> vppctl set ip neighbor static TenGigabitEthernet5/0/0 2001:2::2
>> a0:36:9f:74:73:64
>> vppctl set ip neighbor static TenGigabitEthernet5/0/1 198.19.0.2
>> a0:36:9f:74:73:66
>> vppctl set interface nat64 in TenGigabitEthernet5/0/0
>> vppctl set interface nat64 out TenGigabitEthernet5/0/1
>> vppctl nat64 add prefix 64:ff9b::/96
>> vppctl nat64 add pool address 198.19.0.1
>>
>> As for VPP, first I used two workers, but then I also tried without
>> workers, using only the main core. Unfortunately, VPP crashed in both
>> cases, but with somewhat different messages in the syslog. (Previously I
>> tested both setups with IPv6 packet forwarding and they worked with an
>> excellent performance.)
>>
>> The error messages in the syslog when I used two workers:
>>
>> Nov  7 16:32:02 p109 vnet[2479]: received signal SIGSEGV, PC
>> 0x7fa86f138168, faulting address 0x4f8
>> Nov  7 16:32:02 p109 vnet[2479]: #0  0x7fa8b2158137 0x7fa8b2158137
>> Nov  7 16:32:02 p109 vnet[2479]: #1  0x7fa8b2086730 0x7fa8b2086730
>> Nov  7 16:32:02 p109 vnet[2479]: #2  0x7fa86f138168 0x7fa86f138168
>> Nov  7 16:32:02 p109 vnet[2479]: #3  0x7fa86f11d228 0x7fa86f11d228
>> Nov  7 16:32:02 p109 vnet[2479]: #4  0x7fa8b20fbe62 0x7fa8b20fbe62
>> Nov  7 16:32:02 p109 

Re: [vpp-dev] Gerrit Review Id 37651

[filvarga]

Hi,

Looks good to me. But I can see that in non of the cli commands
 if (!unformat_user (input, unformat_line_input, line_input))
   return 0;
is used.

Have a look at Daves patch:
e697caf9f84408fd7e2caa9bed58946f068e4c9c

Best regards,
Filip Varga


so 12. 11. 2022 o 5:14 lihuawei  napísal(a):

> Hi Dave Barach && community,
>
> I have added a fix as gerrit review id 37651.
>
> *gerrit link: https://gerrit.fd.io/r/c/vpp/+/37651
> *
>
> *short description: *fix classify session cli. Return error if there is
> unkown input.
>
> Please have a look and review.
>
> Best regards,
> Huawei LI
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22171): https://lists.fd.io/g/vpp-dev/message/22171
Mute This Topic: https://lists.fd.io/mt/94974653/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Some NAT API Error Values

[filvarga]

Hi,

Thank you for your notes and pointing out the issue. Feel free to submit
any changes in the future and add appropriate people to your review (based
on maintainers list). For now I am posting a quick fix. As the nat44-ed
control plane is undergoing a continuous huge refactor I wouldn't advise
too much diverting from its current state. Better solution here is to check
the return value of enable / disable calls and then set rv appropriately.

For now (based on return codes from vnet/error.h) I will use these
VNET_API_ERROR_FEATURE_DISABLED
VNET_API_ERROR_UNSUPPORTED
for enable/disable api errors rather than introducing something new that
can get removed in near future.

Best regards,
Filip Varga


st 23. 11. 2022 o 9:47 Jon Loeliger via lists.fd.io  napísal(a):

> Hi VPPeople,
>
> I would like to open a discussion about some strange code and return values
> from a few of the NAT CLI and API interface functions.
>
> My quest for a reasonable handling when my management plane attempted to
> enable an already-enabled NAT 44 ED feature was handled poorly.  It turns
> out,
> rather than a negative API return value with an error indicating that the
> feature
> was already enabled, nor did it return 0 indicating that all was well.
> Instead it
> returned a positive 1 value.  As there is no indication of return value in
> the reply
> API call, a normal, negative value was expected.
>
> When I first read through
> the vl_api_nat44_ed_plugin_enable_disable_t_handler()
> and the underlying nat44_plugin_enable() code, I couldn't see where it even
> returned anything other than a straight open-coded 0 return value.
>
> A closer read showed two seriously weird coding issues, both related.  At
> the beginning
> of nat44_plugin_enable() we find this code from
> src/plugin/nat/nat44_ed_api.c
> and nat44_ed.c:
>
> int
> nat44_plugin_enable (nat44_config_t c)
> {
>   snat_main_t *sm = &snat_main;
>
>   fail_if_enabled ();
>
>   sm->forwarding_enabled = 0;
>   sm->mss_clamping = 0;
>   ...
>
> The apparent function fail_if_enabled() isn't a function at all:
>
> #define fail_if_enabled()
> \
>   do
>\
> {
> \
>   snat_main_t *sm = &snat_main;
> \
>   if (PREDICT_FALSE (sm->enabled))
>\
> {
> \
>   nat_log_err ("plugin enabled");
> \
>   return 1;
> \
> }
> \
> }
> \
>   while (0)
>
> It is a single compound statement with the hidden side effect
> of returning directly out of the containing function with, get
> this, a return value of 1.  This return value is then used in
> turn directly as the error return value for an API call:
>
> static void
> vl_api_nat44_ed_plugin_enable_disable_t_handler (
>   vl_api_nat44_ed_plugin_enable_disable_t *mp)
> {
> ...
>   if (mp->enable)
> {
>   if ((mp->flags & NAT44_API_IS_STATIC_MAPPING_ONLY) ||
>   (mp->flags & NAT44_API_IS_CONNECTION_TRACKING))
> {
>   rv = VNET_API_ERROR_UNSUPPORTED;
> }
>   else
> {
>   c.sessions = ntohl (mp->sessions);
>   c.inside_vrf = ntohl (mp->inside_vrf);
>   c.outside_vrf = ntohl (mp->outside_vrf);
>
>   rv = nat44_plugin_enable (c);
> }
> }
> ...
>
> OK, I am proposing two fixes here.
>
> First, hiding unexpected control flow in a #define like this is bad for
> many reasons.
> Allowing for a nominal function to determine if the feature is already
> enabled
> or not is fine.  It should look like an actual inline function with a
> legitimate return value.
> It should likely be a TRUE/FALSE "is enabled" testing function,  It should
> probably
> leave the interpretation of that value to the caller.  That is, the caller
> should issue error
> messages and generate proper return codes accordingly.
>
> Second, the actual return values for the API should be both listed in the
> API error values
> enumeration and be negative for errors.  If there is a need, and I
> maintainer there is, for
> an error code that indicates "already enabled", it should be added if not
> already present.
>
> Anyone have any problem with me submitting patches to fix these issues?
>
> Thanks,
> jdl
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22234): https://lists.fd.io/g/vpp-dev/message/22234
Mute This Topic: https://lists.fd.io/mt/95222842/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Some NAT API Error Values

[filvarga]

Hi,

I understand your perspective. But you have to think in a longer
perspective of NAT changes. The concept of enabling / disabling plugins on
the go is not super common among VPP. This was just an addition for SDN
deployments so configuration through startup config can be avoided and
reallocation - change in number of sessions etc. can be done on the fly.
Because of that we haven't yet committed to a "proper" way to handle
events. Why did I choose those return values ? Because UNSUPPORTED is
widely used if some action is not supported at the moment. This also
applies to calling different control plane logic through API on nat44-ed
and among other plugins. So trying to enable already enabled plugin returns
UNSUPPORTED and trying to disable plugin that is not configured will result
in VNET_API_ERROR_UNSUPPORTED. Maybe addition to add
VNET_API_ERROR_FEATURE_ENABLED could work for you. What I would advise is
to wait for this patch to get merged and then add additional
VNET_API_ERROR_FEATURE_ENABLED into vnet/error.h and changing the return
value (just so we comply with how patches should be submitted).

I will do the same for EI. Thank you for pointing that out.

Also consider that the part of code returning VNET_API_ERROR_UNSUPPORTED in
nat44-ed enable/disable call for unsupported flags is just a backward API
compatibility logic. That means it should never happen so relying on
VNET_API_ERROR_UNSUPPORTED if plugin is already enabled should be
sufficient.

As I mentioned before NAT44-ED code architecture isn't ideal but that is
because of its history and both ED and EI and other flavors of NAT where
one big plugin previously (SNAT) now we are moving forward and cleaning it
up (or I am).

Thank you for your interest.

Best regards,
Filip Varga


st 23. 11. 2022 o 12:59 Jon Loeliger via lists.fd.io  napísal(a):

> On Wed, Nov 23, 2022 at 12:25 PM filvarga  wrote:
>
>> Hi,
>>
>> Thank you for your notes and pointing out the issue. Feel free to submit
>> any changes in the future and add appropriate people to your review (based
>> on maintainers list).
>>
>
> Thanks, will do!
>
> For now I am posting a quick fix. As the nat44-ed control plane is
>> undergoing a continuous huge refactor I wouldn't advise too much diverting
>> from its current state.\
>>
>
> I might point out that this applies to both ED and EI.  They both display
> the same issues.
>
>
>> Better solution here is to check the return value of enable / disable
>> calls and then set rv appropriately.
>>
>
> Exactly.  But in this case I couldn't because it was buried in a macro
> that didn't return.
>
>
>> For now (based on return codes from vnet/error.h) I will use these
>> VNET_API_ERROR_FEATURE_DISABLED
>> VNET_API_ERROR_UNSUPPORTED
>> for enable/disable api errors rather than introducing something new that
>> can get removed in near future.
>>
>
> Those error values miss the important case of identifying the case where
> one is
> trying to enable the already-enabled feature.  We need to know and
> identify that
> case, just as many of the other Features do.
>
> Thanks,
> jdl
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22237): https://lists.fd.io/g/vpp-dev/message/22237
Mute This Topic: https://lists.fd.io/mt/95222842/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Some NAT API Error Values

[filvarga]

Hi,

https://gerrit.fd.io/r/c/vpp/+/37695

Here you go:

FEATURE_ALREADY_DISABLED
FEATURE_ALREADY_ENABLED

There is much work to be done on the error tracking side of the whole nat
api though. I wouldn't rely to much on specific errors more on failure /
success for now.

Best regards,
Filip Varga


st 23. 11. 2022 o 13:59 filvarga via lists.fd.io  napísal(a):

> Hi,
>
> I understand your perspective. But you have to think in a longer
> perspective of NAT changes. The concept of enabling / disabling plugins on
> the go is not super common among VPP. This was just an addition for SDN
> deployments so configuration through startup config can be avoided and
> reallocation - change in number of sessions etc. can be done on the fly.
> Because of that we haven't yet committed to a "proper" way to handle
> events. Why did I choose those return values ? Because UNSUPPORTED is
> widely used if some action is not supported at the moment. This also
> applies to calling different control plane logic through API on nat44-ed
> and among other plugins. So trying to enable already enabled plugin returns
> UNSUPPORTED and trying to disable plugin that is not configured will result
> in VNET_API_ERROR_UNSUPPORTED. Maybe addition to add
> VNET_API_ERROR_FEATURE_ENABLED could work for you. What I would advise is
> to wait for this patch to get merged and then add additional
> VNET_API_ERROR_FEATURE_ENABLED into vnet/error.h and changing the return
> value (just so we comply with how patches should be submitted).
>
> I will do the same for EI. Thank you for pointing that out.
>
> Also consider that the part of code returning VNET_API_ERROR_UNSUPPORTED
> in nat44-ed enable/disable call for unsupported flags is just a backward
> API compatibility logic. That means it should never happen so relying on
> VNET_API_ERROR_UNSUPPORTED if plugin is already enabled should be
> sufficient.
>
> As I mentioned before NAT44-ED code architecture isn't ideal but that is
> because of its history and both ED and EI and other flavors of NAT where
> one big plugin previously (SNAT) now we are moving forward and cleaning it
> up (or I am).
>
> Thank you for your interest.
>
> Best regards,
> Filip Varga
>
>
> st 23. 11. 2022 o 12:59 Jon Loeliger via lists.fd.io  netgate@lists.fd.io> napísal(a):
>
>> On Wed, Nov 23, 2022 at 12:25 PM filvarga  wrote:
>>
>>> Hi,
>>>
>>> Thank you for your notes and pointing out the issue. Feel free to submit
>>> any changes in the future and add appropriate people to your review (based
>>> on maintainers list).
>>>
>>
>> Thanks, will do!
>>
>> For now I am posting a quick fix. As the nat44-ed control plane is
>>> undergoing a continuous huge refactor I wouldn't advise too much diverting
>>> from its current state.\
>>>
>>
>> I might point out that this applies to both ED and EI.  They both display
>> the same issues.
>>
>>
>>> Better solution here is to check the return value of enable / disable
>>> calls and then set rv appropriately.
>>>
>>
>> Exactly.  But in this case I couldn't because it was buried in a macro
>> that didn't return.
>>
>>
>>> For now (based on return codes from vnet/error.h) I will use these
>>> VNET_API_ERROR_FEATURE_DISABLED
>>> VNET_API_ERROR_UNSUPPORTED
>>> for enable/disable api errors rather than introducing something new that
>>> can get removed in near future.
>>>
>>
>> Those error values miss the important case of identifying the case where
>> one is
>> trying to enable the already-enabled feature.  We need to know and
>> identify that
>> case, just as many of the other Features do.
>>
>> Thanks,
>> jdl
>>
>>
>>
>>
>>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22244): https://lists.fd.io/g/vpp-dev/message/22244
Mute This Topic: https://lists.fd.io/mt/95222842/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Forwarding Specific Packet with LCP Plugin

[filvarga]

Hi Burcu,

Yes you are able to use VPP host stack implementation with LD_PRELOAD.
Please refer to https://wiki.fd.io/view/VPP/HostStack/LDP/sshd .

Best regards,
Filip Varga


ut 14. 2. 2023 o 14:50 Matthew Smith via lists.fd.io  napísal(a):

>
> You set the next hop address to the same as the local interface address:
>
> On Tue, Feb 14, 2023 at 7:42 AM Burcu YUKSEL <
> burcu.yuk...@ulakhaberlesme.com.tr> wrote:
>
> [...]
>
>> set int ip address memif0/0 10.10.1.1/24
>>
> [...]
>
>> abf policy add id 0 acl 0 via 10.10.1.1 memif0/0
>>
>
> If you want packets matching the ACL to be sent to 10.10.1.4 as in your
> original diagram, the abf policy should be via 10.10.1.4, not 10.10.1.1.
>
> -Matt
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22592): https://lists.fd.io/g/vpp-dev/message/22592
Mute This Topic: https://lists.fd.io/mt/96850285/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Fixing nat44ed vrf api handlers

[filvarga]

Hi,

Yes I fully agree with Andrew on changing APIs. Though the api was broken
in the first place. If used incorrect message is returned. Because of that
I am not even sure if it is functional at all. It is more likely that
nobody before addressed this issue because this feature is not used.

So I would suggest either to set it as deprecated and add v2 which will be
flagged as experimental or change it on master because It might not be even
functional.

Best regards,
Filip Varga


st 22. 3. 2023 o 14:11 Andrew Yourtchenko  napísal(a):

> Hey Daniel,
>
> I had a quick look and it looks like the APIs in question are also not
> marked as experimental ?
>
> If I am right, then to me seems like a silent behavior change to a
> production API - something we have heard repeated complaints from the
> downstream consumers for….
>
> I had -2’d it for now - we should definitely discuss it here first; as is
> i would consider it a no-go even for a master, but I am happy to hear
> others opinions and be convinced otherwise :-)
>
> --a
>
> On 22 Mar 2023, at 10:36, Daniel Béreš  wrote:
>
> 
>
> Hello Guys,
>
> I wrote a short patch to fix a couple api handlers for nat44ed [1] .
> It was probably forgotten, so I'm
> reminding myself.
>
> I still have a question about whether it is possible to cherry-pick the
> patch to vpp v23.02 and 22.10.
>
> [1] https://gerrit.fd.io/r/c/vpp/+/38459
>
>
> Thanks,
> Daniel
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22748): https://lists.fd.io/g/vpp-dev/message/22748
Mute This Topic: https://lists.fd.io/mt/97774402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Fixing nat44ed vrf api handlers

[filvarga]

If you decide to split the patch and do a second version. I would like to
see the first version set as deprecated. So when removed we can put it
again in without having to have _v2 _v3 etc.

Best regards,
Filip Varga


st 22. 3. 2023 o 15:33 Daniel Béreš  napísal(a):

> Thanks for the reasonable explanations.
>
> So the option could be splitting it into two patches. The first could fix
> replies and the second could contain a new experimental API
> nat44_ed_vrf_tables_send_details_v2.
>
> I think it might be okay after that.
>
> Daniel
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22751): https://lists.fd.io/g/vpp-dev/message/22751
Mute This Topic: https://lists.fd.io/mt/97774402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-