Re: [vpp-dev] SNAT, nat44 with static mapping of whole subnet
Hi,
From the first look i can see you are not enabling deterministic plugin like
you are nat44 plugin. Secondly mixing both plugins isn't fully supported. There
could be probably some issues. I am not completely sure about your use cases
but using static mappings in this kind of scenario isn't viable solution.
If you just want each subnet to have different outside address. You should
definitely use PAT - aka dynamic mapping and put all of those inside subnets in
different VRF's after that add nat address for each vrf.
VRF1 192.168.0/24 -> 10.0.0.1
VRF2 192.168.1/24 - > 10.0.02
etc.
Be sure to set inside - vrf interfaces as inside and outside interface as
outside.
Use nat44-ed plugin.
Best regards,
Filip
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Adrian Imboden
Sent: Thursday, January 20, 2022 1:55 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] SNAT, nat44 with static mapping of whole subnet
Importance: High
Hi all
I'm using vpp only recently and I am very happy with the way it works.
I am currently trying to replace my linux based router with a linux based vpp
router.
- I use version release 21.10
- I have a small ipv4 /24 network and an additional static ip
- I have multiple subnets (test1, test2 in the example)
What I want to do is:
- Do SNAT
- Map each subnet to a single ipv4 address
- For my test: assume 10.10.100.50-10.10.100.52 are my public ips
What I have now is the following:
```
comment { == setting up testnet1 } create tap id 1
host-if-name testnet1 host-ip4-addr 192.168.10.1/23 create loopback interface
instance 1 set interface ip address loop1 192.168.10.255/23
set int l2 bridge tap1 1
set int l2 bridge loop1 1 bvi
set int l2 bridge TenGigabitEthernet8/0/0 1
comment { == setting up testnet2 } create tap id 2
host-if-name testnet2 host-ip4-addr 192.168.12.1/23 create loopback interface
instance 2 set interface ip address loop2 192.168.12.255/23
set int l2 bridge tap2 2
set int l2 bridge loop2 2 bvi
set interface ip address TenGigabitEtherneta/0/3 10.10.100.50/23 set interface
ip address TenGigabitEtherneta/0/3 10.10.100.51/23 set interface ip address
TenGigabitEtherneta/0/3 10.10.100.52/23
nat44 enable
nat44 add address 10.10.100.50
nat44 add address 10.10.100.51
nat44 add address 10.10.100.52
set interface nat44 out TenGigabitEtherneta/0/3 set interface nat44 in loop1
set interface nat44 in loop2
ip route add 10.10.100.0/23 via TenGigabitEtherneta/0/3
comment { = port forwarding }
det44 add static mapping udp local 102.168.10.33 1234 external
10.10.100.51 1234
comment { enable all interfaces }
set int state tap1 up
set int state loop1 up
set int state TenGigabitEthernet8/0/0 up
set int state tap2 up
set int state loop2 up
set int state TenGigabitEtherneta/0/3 up
```
Now I have the problem that only 10.10.100.50 gets used (or until the
ports are used up I assume).
det44 would support my use case with:
```
det44 add in 192.168.10.0/23 out 10.10.100.51/32
det44 add in 192.168.20.0/23 out 10.10.100.52/32
```
but det44 does not support port forwarding.
and nat44 only supports mapping each host one by one.
In my case I could add all IPs (512 IPs per net). Not pretty, but doable.
My questions:
Do I have an error in my thoughts?
Is there something like this planned?:
```
nat44 add static mapping local 192.168.10.0/23 external 10.10.100.51
```
If not, would this addition be ok? If yes, I may invest some coding time :)
Thanks very much and greetings
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20779): https://lists.fd.io/g/vpp-dev/message/20779
Mute This Topic: https://lists.fd.io/mt/88549403/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Is it too late for Wireguard patches getting in for VPP22.02?
Aie, seems I wrote the reply but got distracted and didn’t hit “send”.. sorry for that… thanks Matt and Fan for clarification, indeed I missed the forest behind the lot of trees! Please feel free to do the cherrypicks for these 4 into stable/2202 within pre-RC2 window., i will merge them. Also seems seems like coverity found something to complain about in /src/plugins/wireguard/wireguard_output_tun.c: 285 in wg_add_to_async_frame() - could the SME take a glance at it ? --a > On 19 Jan 2022, at 17:47, Zhang, Roy Fan wrote: > > Thanks Matthew to point this out. > > To add a bit more detail here > Wireguard data-path encryption and decryption uses aad size of 0. Hence we > have to add new async AEAD op ID to represent this aad size. > > Regards, > Fan > > From: Matthew Smith > Sent: Wednesday, January 19, 2022 4:36 PM > To: Andrew Yourtchenko > Cc: Zhang, Roy Fan ; vpp-dev ; > Andrew Yourtchenko (ayourtch) ; Kinsella, Ray > ; Oginski, GabrielX > Subject: Re: [vpp-dev] Is it too late for Wireguard patches getting in for > VPP22.02? > Asdfasd > Hi Andrew, > > The change in crypto.h that you called out as being whitespace-only actually > changes more than whitespace... It also appends '_ (CHACHA20_POLY1305, > "chacha20-poly1305", 32, 16, 0)' to foreach_crypto_aead_async_alg. > > -Matt > > > On Wed, Jan 19, 2022 at 10:21 AM Andrew Yourtchenko > wrote: > Hi Fan, > > With my release manager hat on: > > the first three patches are solely contained (minus seemingly > whitespace change in 34660? can it be avoided ?) within wireguard > plugin, which has "experimental" status, with which I would be happy > to err on the side of keeping the velocity - so once the nit i pointed > out is taken care of, I would be happy to merge the cherry-picks into > the stable/2202, provided it is "soon" for some very proximate value > of "soon" :) > > the last patch to crypto-dev is an improvement, and looks fairly > straightforward addition, backwards compatible, and was +2'd by Damjan > back in December. So, from the "technical" standpoint it should have > been in, but there was new year break period, etc, etc. So I would > again would be fine with merging the cherry-pick into stable/2202, but > for this one" the value of "soon" should not exceed "end of this > week". > > In case no-one from the community objects to the above by this Friday > 12:00 UTC, let's get these as cherry-picks into stable/2202. > > (p.s.: the 22.02 RC1 is not tagged yet, but the v22.06-rc0 tag is > already on master, I would rather not mess with that). > > --a > > > On 1/19/22, Fan Zhang wrote: > > Hi, > > > > Sorry for the late notice, but we have a bunch of patches waiting to be > > reviewed/merged if possible for VPP22.02. > > > > The patches do 2 things > > > > * Optimizing wireguard performance by introducing burst processing of > > packets and chacha-poly encryption/decryption. > > * Adding async mode to wireguard so the crypto can be processed by > > sw-crypto-scheduler or QAT. > > > > They are > > https://gerrit.fd.io/r/c/vpp/+/34324 > > https://gerrit.fd.io/r/c/vpp/+/34660/2 > > https://gerrit.fd.io/r/c/vpp/+/34661/2 > > https://gerrit.fd.io/r/c/vpp/+/34662/4 > > > > We know the patches are not perfect - as Matthew already pointed out there > > are some improvements can be done (thank you very much Matthew!). > > The bottom line is > > > > * They passed the wireguard unit tests, and we will keep improving > > them. > > * The code change had >5% performance improvement with small packets. > > > > But are they too late for VPP22.02? Much appreciate for the help in > > advance! > > > > Regards, > > fan > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20778): https://lists.fd.io/g/vpp-dev/message/20778 Mute This Topic: https://lists.fd.io/mt/88537247/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPSec/QAT offload config
Once more than 1 worker core is added in startup conf, crash is not observed
during init phase. But when I set the async mode on, it crashes in same place.
Do I need to set async mode on to use QAT ? Do I need to enable any specific
plugin ?
cpu
{
corelist-workers 9-12
main-core 13
}
DBGvpp# set ipsec async mode on
Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x773713c9 in vnet_crypto_update_cm_dequeue_handlers () at
/home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:337
337 if (!e->dequeue_handler)
(gdb)
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Govindarajan
> Mohandoss via lists.fd.io
> Sent: Friday, January 21, 2022 12:24 PM
> To: vpp-dev
> Cc: Yoan Picchi ; nd ; nd
>
> Subject: [vpp-dev] IPSec/QAT offload config
>
> Hi Experts,
> We are trying to run IPSec with QAT offload and did the following dpdk
> config in startup conf. When we run VPP, it crashes in the init phase (Before
> reaching out to VPP shell). Can you please help us with proper config to
> enable QAT ?
> We did a sanity test with standalone DPDK IPSec application and it works fine
> with QAT card.
>
> dpdk
> {
> dev :af:00.0 #NIC
> dev :39:01.0 #QAT
> log-level debug
> dev default
> {
> num-rx-desc 1024
> num-tx-desc 1024
> }
> }
>
>
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x773713c9 in vnet_crypto_update_cm_dequeue_handlers () at
> /home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:337
> 337 if (!e->dequeue_handler)
> (gdb) bt
> #0 0x773713c9 in vnet_crypto_update_cm_dequeue_handlers () at
> /home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:337
> #1 0x77371d69 in vnet_crypto_request_async_mode (is_enable=1)
> at /home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:678
> #2 0x7ffef5b0e4ff in dpdk_cryptodev_init (vm=0x7ffef685a680)
> at
> /home/govmoh01/vpp_qat/vpp/src/plugins/dpdk/cryptodev/cryptodev.c:12
> 00
> #3 0x7ffef5af1608 in dpdk_process (vm=0x7ffef685a680,
> rt=0x7ffef8176d00, f=0x0)
> at /home/govmoh01/vpp_qat/vpp/src/plugins/dpdk/device/init.c:1417
> #4 0x76e513ed in vlib_process_bootstrap (_a=140733006596280) at
> /home/govmoh01/vpp_qat/vpp/src/vlib/main.c:1235
> #5 0x76cefc38 in clib_calljmp () at
> /home/govmoh01/vpp_qat/vpp/src/vppinfra/longjmp.S:123
> #6 0x7ffef4ddc8b0 in ?? ()
> #7 0x76e50e0f in vlib_process_startup (vm=0x7ffef685a680,
> p=0x7ffef8176d00, f=0x0)
>
> Thanks
> Govind
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20777): https://lists.fd.io/g/vpp-dev/message/20777
Mute This Topic: https://lists.fd.io/mt/88589344/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] IPSec/QAT offload config
Hi Experts,
We are trying to run IPSec with QAT offload and did the following dpdk config
in startup conf. When we run VPP, it crashes in the init phase (Before reaching
out to VPP shell). Can you please help us with proper config to enable QAT ?
We did a sanity test with standalone DPDK IPSec application and it works fine
with QAT card.
dpdk
{
dev :af:00.0 #NIC
dev :39:01.0 #QAT
log-level debug
dev default
{
num-rx-desc 1024
num-tx-desc 1024
}
}
Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x773713c9 in vnet_crypto_update_cm_dequeue_handlers () at
/home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:337
337 if (!e->dequeue_handler)
(gdb) bt
#0 0x773713c9 in vnet_crypto_update_cm_dequeue_handlers () at
/home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:337
#1 0x77371d69 in vnet_crypto_request_async_mode (is_enable=1)
at /home/govmoh01/vpp_qat/vpp/src/vnet/crypto/crypto.c:678
#2 0x7ffef5b0e4ff in dpdk_cryptodev_init (vm=0x7ffef685a680)
at /home/govmoh01/vpp_qat/vpp/src/plugins/dpdk/cryptodev/cryptodev.c:1200
#3 0x7ffef5af1608 in dpdk_process (vm=0x7ffef685a680, rt=0x7ffef8176d00,
f=0x0)
at /home/govmoh01/vpp_qat/vpp/src/plugins/dpdk/device/init.c:1417
#4 0x76e513ed in vlib_process_bootstrap (_a=140733006596280) at
/home/govmoh01/vpp_qat/vpp/src/vlib/main.c:1235
#5 0x76cefc38 in clib_calljmp () at
/home/govmoh01/vpp_qat/vpp/src/vppinfra/longjmp.S:123
#6 0x7ffef4ddc8b0 in ?? ()
#7 0x76e50e0f in vlib_process_startup (vm=0x7ffef685a680,
p=0x7ffef8176d00, f=0x0)
Thanks
Govind
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20776): https://lists.fd.io/g/vpp-dev/message/20776
Mute This Topic: https://lists.fd.io/mt/88589344/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] PING not taking desired interface to go out when there are ECMP routes
Hi Subramanya, In general a router implements the weak host model, see https://datatracker.ietf.org/doc/html/rfc1122#section-3.3.4 In the weak host model the source address selected is independent of the outgoing interface. > I'm trying to ping, and I observe that there is a mismatch between the > interface taken by the packet to go out and the source IP in the packet (when > there are ecmp routes). > The issue is that when I try to ping, and there are ECMP routes, the > interface it is going out and the source IP value filled in the IP header is > different, and also packet is not going out of the desired interface, if I > use the "source" option in ping.(even though IP is correct). > > Suppose, there are two sub-interfaces configured this way: > > TwentyFiveGEthernet0/7/0.13 (up): > L3 10.10.10.1/29 ip4 table-id 1 fib-idx 1 > > TwentyFiveGEthernet0/8/0.14 (up): > L3 10.10.10.17/29 ip4 table-id 1 fib-idx 1 > > And hardware Addresses are this way: > > TwentyFiveGEthernet0/7/0 3 up TwentyFiveGEthernet0/7/0 > Link speed: 25 Gbps > Ethernet address fa:16:3e:xx:xx:x1 > > TwentyFiveGEthernet0/8/0 4 up TwentyFiveGEthernet0/8/0 > Link speed: 25 Gbps > Ethernet address fa:16:3e:xx:xx:xx > > > > show ip fib output is as follows: > 0.0.0.0/0 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:31 buckets:2 uRPF:199 to:[0:0]] > [0] [@5]: ipv4 via 172.19.171.113 TwentyFiveGEthernet0/7/0.1328: mtu:1500 > next:6 a47b2cf5dbf9fa163ecda406810005300800 > [1] [@5]: ipv4 via 172.19.171.121 TwentyFiveGEthernet0/8/0.1329: mtu:1500 > next:7 a47b2cfaf0edfa163eb0de2f810005310800 > > > Now, suppose I ping using interface TwentyFiveGEthernet0/7/0.13, [ ping > 8.8.8.8 source TwentyFiveGEthernet0/7/0.13 ] > it is filling the IP of that interface which is 10.10.10.1, but the > outgoing packet is going out of interface TwentyFiveGEthernet0/8/0.14 and the > mac and vlan is also taken of TwentyFiveGEthernet0/8/0.13, Are you saying that VPP sends a packet out on 0.14 with a source MAC from 0.13? If that's the case, that's clearly a bug. > Also, using the option "table-id"[ping 8.8.8.8 table-id 1], the same issue > is seen, where there is a mismatch of the source ip filled in packet and the > packet is taking a different interface to go out. Are you saing the source address chosen is not part of table 1? If so that is also a bug with the source address selection done by ping. > So I'm guessing that once the ping plugin fills the source IP address in > the packet, and when the packet gets to the next node i.e. "ip4-lookup" node, > it is not considered strictly to go out of the interface with which the user > has specified in ECMP case. The ping "source" command doesn't specify outgoing interface, it specifies which interface the SAS algorithm should try to get a source address from. Suggestions for improvements? We could possibly add an option that would allow you to set outgoing interface in case of ECMP. Or even a toggle to select strong host model too. Best regards, Ole -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20775): https://lists.fd.io/g/vpp-dev/message/20775 Mute This Topic: https://lists.fd.io/mt/88580236/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] PING not taking desired interface to go out when there are ECMP routes
Hi, I'm trying to ping, and I observe that there is a mismatch between the interface taken by the packet to go out and the source IP in the packet (when there are ecmp routes). The issue is that when I try to ping, and there are ECMP routes, the interface it is going out and the source IP value filled in the IP header is different, and also packet is not going out of the desired interface, if I use the "source" option in ping.(even though IP is correct). *Suppose, there are two sub-interfaces configured this way:* TwentyFiveGEthernet0/7/0.13 (up): L3 10.10.10.1/29 ip4 table-id 1 fib-idx 1 TwentyFiveGEthernet0/8/0.14 (up): L3 10.10.10.17/29 ip4 table-id 1 fib-idx 1 *And hardware Addresses are this way:* TwentyFiveGEthernet0/7/0 3 up TwentyFiveGEthernet0/7/0 Link speed: 25 Gbps Ethernet address fa:16:3e:xx:xx:x1 TwentyFiveGEthernet0/8/0 4 up TwentyFiveGEthernet0/8/0 Link speed: 25 Gbps Ethernet address fa:16:3e:xx:xx:xx * show ip fib output is as follows:* 0.0.0.0/0 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:31 buckets:2 uRPF:199 to:[0:0]] [0] [@5]: ipv4 via 172.19.171.113 TwentyFiveGEthernet0/7/0.1328: mtu:1500 next:6 a47b2cf5dbf9fa163ecda406810005300800 [1] [@5]: ipv4 via 172.19.171.121 TwentyFiveGEthernet0/8/0.1329: mtu:1500 next:7 a47b2cfaf0edfa163eb0de2f810005310800 Now, suppose I ping using interface TwentyFiveGEthernet0/7/0.13, [ *ping 8.8.8.8 source TwentyFiveGEthernet0/7/0.13* ] it is filling the *IP of that interface which is 10.10.10.1*, but the* outgoing packet is going out of interface TwentyFiveGEthernet0/8/0.14 and the mac and vlan is also taken of TwentyFiveGEthernet0/8/0.13,* Also, using the option "table-id"[ping 8.8.8.8 table-id 1], the same issue is seen, where there is a mismatch of the source ip filled in packet and the packet is taking a different interface to go out. So I'm guessing that once the ping plugin fills the source IP address in the packet, and when the packet gets to the next node i.e. "ip4-lookup" node, it is not considered strictly to go out of the interface with which the user has specified in ECMP case. Is this a bug? Can someone please help with this? Thanks, Subramanya -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20774): https://lists.fd.io/g/vpp-dev/message/20774 Mute This Topic: https://lists.fd.io/mt/88580236/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
