date:20220117

Re: [vpp-dev] linux-cp + nat44 possible?

2022-01-17 Thread René Weiss


Hi Dave

Thanks, this looks like an extended version of 
https://fd.io/docs/vpp/v2009/usecases/homegateway.html


I will take a closer look, especially at the ipv6 section because I was 
already wondering how to do the things I'm currently doing with 
radvd/wide-dhcpv6-client with VPP.


Another open questions (and the main reason I was asking for linux-cp) 
is receiving IPTV over multicast.


On Linux I'm using imgpproxy and udpxy (http://www.udpxy.com/, a 
multicast-UDP to HTTP relay) for this and while it's not essential for 
me, it still would be nice to continue to be able to use it.


Maybe you (or anyone else here) can give me a pointer in the right 
direction?


Thanks.
René

Am 17.01.22 um 20:58 schrieb Dave Barach:

https://s3-docs.fd.io/vpp/22.02/usecases/home_gateway.html - I've used vpp as a 
home gateway for years.

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of René Weiss
Sent: Monday, January 17, 2022 12:47 PM
To: vpp-dev 
Subject: [vpp-dev] linux-cp + nat44 possible?

Hi

Is it possible to use linux-cp and nat44 together?

I'm currently playing with VPP to see if I would be able to use it on my Linux 
home gateway (mostly as an iptables/nftables replacement).

And because there I have an external and (at least) one internal interface I 
tried (unsuccessfully) to replicate that with VPP.

I was able to create a basic NAT setup based on "VPP_Home_Gateway" from the wiki where 
you get a single "lstack" interface in Linux.

Likewise, I also was able to pass VPP interfaces to Linux with "lcp create  
host-if ".

But as soon as I try to combine the two (setup nat44 while using the forwarded 
interfaces) the external interface stops working for the Linux on the machine.

Is this something that simply will not work with VPP, or have I just not found 
the right settings yet?

Thanks,
René






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20741): https://lists.fd.io/g/vpp-dev/message/20741
Mute This Topic: https://lists.fd.io/mt/88490068/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] linux-cp + nat44 possible?

2022-01-17 Thread René Weiss




Am 17.01.22 um 21:53 schrieb René Weiss:

Hi Dave

Thanks, this looks like an extended version of 
https://fd.io/docs/vpp/v2009/usecases/homegateway.html


I will take a closer look, especially at the ipv6 section because I was 
already wondering how to do the things I'm currently doing with 
radvd/wide-dhcpv6-client with VPP.


Another open questions (and the main reason I was asking for linux-cp) 
is receiving IPTV over multicast.


On Linux I'm using imgpproxy and udpxy (http://www.udpxy.com/, a 
multicast-UDP to HTTP relay) for this and while it's not essential for 
me, it still would be nice to continue to be able to use it.


Maybe you (or anyone else here) can give me a pointer in the right 
direction?


Thanks.
René

Am 17.01.22 um 20:58 schrieb Dave Barach:
https://s3-docs.fd.io/vpp/22.02/usecases/home_gateway.html - I've used 
vpp as a home gateway for years.


HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of René Weiss
Sent: Monday, January 17, 2022 12:47 PM
To: vpp-dev 
Subject: [vpp-dev] linux-cp + nat44 possible?

Hi

Is it possible to use linux-cp and nat44 together?

I'm currently playing with VPP to see if I would be able to use it on 
my Linux home gateway (mostly as an iptables/nftables replacement).


And because there I have an external and (at least) one internal 
interface I tried (unsuccessfully) to replicate that with VPP.


I was able to create a basic NAT setup based on "VPP_Home_Gateway" 
from the wiki where you get a single "lstack" interface in Linux.


Likewise, I also was able to pass VPP interfaces to Linux with "lcp 
create  host-if ".


But as soon as I try to combine the two (setup nat44 while using the 
forwarded interfaces) the external interface stops working for the 
Linux on the machine.


Is this something that simply will not work with VPP, or have I just 
not found the right settings yet?


Thanks,
René






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20740): https://lists.fd.io/g/vpp-dev/message/20740
Mute This Topic: https://lists.fd.io/mt/88490068/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] linux-cp + nat44 possible?

2022-01-17 Thread Dave Barach

https://s3-docs.fd.io/vpp/22.02/usecases/home_gateway.html - I've used vpp as a 
home gateway for years. 

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of René Weiss
Sent: Monday, January 17, 2022 12:47 PM
To: vpp-dev 
Subject: [vpp-dev] linux-cp + nat44 possible?

Hi

Is it possible to use linux-cp and nat44 together?

I'm currently playing with VPP to see if I would be able to use it on my Linux 
home gateway (mostly as an iptables/nftables replacement).

And because there I have an external and (at least) one internal interface I 
tried (unsuccessfully) to replicate that with VPP.

I was able to create a basic NAT setup based on "VPP_Home_Gateway" from the 
wiki where you get a single "lstack" interface in Linux.

Likewise, I also was able to pass VPP interfaces to Linux with "lcp create 
 host-if ".

But as soon as I try to combine the two (setup nat44 while using the forwarded 
interfaces) the external interface stops working for the Linux on the machine.

Is this something that simply will not work with VPP, or have I just not found 
the right settings yet?

Thanks,
René

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

[vpp-dev] linux-cp + nat44 possible?

2022-01-17 Thread René Weiss


Hi

Is it possible to use linux-cp and nat44 together?

I'm currently playing with VPP to see if I would be able to use it on my 
Linux home gateway (mostly as an iptables/nftables replacement).


And because there I have an external and (at least) one internal 
interface I tried (unsuccessfully) to replicate that with VPP.


I was able to create a basic NAT setup based on "VPP_Home_Gateway" from 
the wiki where you get a single "lstack" interface in Linux.


Likewise, I also was able to pass VPP interfaces to Linux with "lcp 
create  host-if ".


But as soon as I try to combine the two (setup nat44 while using the 
forwarded interfaces) the external interface stops working for the Linux 
on the machine.


Is this something that simply will not work with VPP, or have I just not 
found the right settings yet?


Thanks,
René

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20738): https://lists.fd.io/g/vpp-dev/message/20738
Mute This Topic: https://lists.fd.io/mt/88490068/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] linux-cp TAP MTU show issue

2022-01-17 Thread Petr Boltík

Thank you,

Your idea is the same as mine, all commands are executed for if_index 0. I
have already tried to go deeper, but this is out of my knowledge.

Regards
Petr

po 17. 1. 2022 v 14:50 odesílatel Pim van Pelt  napsal:

> Hoi Petr, others,
>
> Petr, in case you were interested to take a look -- I became a bit less
> lazy and started VPP in a debugger, and added a breakpoint in the
> vnet_hw_interface_add_del_mac_address function.
>
>
> DBGvpp# create sub HundredGigabitEthernet15/0/0  10
>
> HundredGigabitEthernet15/0/0.10
>
> DBGvpp# show int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> GigabitEthernet5/0/0  1 down 9000/0/0/0
> GigabitEthernet5/0/1  2 down 9000/0/0/0
> GigabitEthernet5/0/2  3 down 9000/0/0/0
> GigabitEthernet5/0/3  4 down 9000/0/0/0
> HundredGigabitEthernet15/0/0  5 down 9000/0/0/0
> HundredGigabitEthernet15/0/0.10   7 down  0/0/0/0
> HundredGigabitEthernet15/0/1  6 down 9000/0/0/0
> local00 down  0/0/0/0
> DBGvpp# set interface ip address HundredGigabitEthernet15/0/0.10
> 192.0.2.1/30
>
> 
>
> This is the call stack:
> #0  vnet_hw_interface_add_del_mac_address (vnm=0x77f42ec0 ,
> hw_if_index=0, mac_address=0x7fff513e87f0 "\001", is_add=1 '\001')
> at /home/pim/src/vpp/src/vnet/interface.c:1580
> #1  0x777a8b46 in mfib_itf_mac_add_del (itf=0x7fff9c6710c0,
> pfx=0x7fff97c69bcc, add=1) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:167
> #2  0x777a8ad2 in mfib_itf_mac_add (itf=0x7fff9c6710c0,
> pfx=0x7fff97c69bcc) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:176
> #3  0x777ac6a5 in mfib_entry_path_update (mfib_entry_index=1,
> source=MFIB_SOURCE_SPECIAL, rpaths=0x7fff97e0ceb0)
> at /home/pim/src/vpp/src/vnet/mfib/mfib_entry.c:1070
> #4  0x777b353c in mfib_table_entry_paths_update_i (fib_index=0,
> prefix=0x77d096e0 , source=MFIB_SOURCE_SPECIAL,
> entry_flags=MFIB_ENTRY_FLAG_NONE, rpaths=0x7fff97e0ceb0) at
> /home/pim/src/vpp/src/vnet/mfib/mfib_table.c:319
> #5  0x777b31f9 in mfib_table_entry_path_update (fib_index=0,
> prefix=0x77d096e0 , source=MFIB_SOURCE_SPECIAL,
> entry_flags=MFIB_ENTRY_FLAG_NONE, rpath=0x7fff513e89c0) at
> /home/pim/src/vpp/src/vnet/mfib/mfib_table.c:337
> #6  0x7779bbd1 in ip4_mfib_interface_enable_disable
> (sw_if_index=7, is_enable=1) at
> /home/pim/src/vpp/src/vnet/mfib/ip4_mfib.c:158
> #7  0x7720aeec in ip4_add_del_interface_address_internal
> (vm=0x7fff96800680, sw_if_index=7, address=0x7fff513e8dd8,
> address_length=30,
> is_del=0) at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:807
> #8  0x7720a1f1 in ip4_add_del_interface_address
> (vm=0x7fff96800680, sw_if_index=7, address=0x7fff513e8dd8,
> address_length=30, is_del=0)
> at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:839
> #9  0x772017e5 in add_del_ip_address (vm=0x7fff96800680,
> input=0x7fff513e9e40, cmd=0x7fff97b5c518)
> at /home/pim/src/vpp/src/vnet/ip/ip46_cli.c:171
>
> in mfib_itf_mac_add_del(), itf->mfi_sw_if_index==7 (this is the index of
> the just created sub-int), the lookup in line 166 yields si->hw_if_index ==
> 0, which is then passed on to the vnet_hw_interface_add_del_mac_address()
> call, provoking the error, because I think it references phy sw index 0
> (interface local0)?
> DBGvpp# show mfib interface
> mFIB interfaces::
> 0@ HundredGigabitEthernet15/0/0.10: Accept,
> 1@ HundredGigabitEthernet15/0/0.10: Accept,
>
> Curiously, I would've expected si->hw_if_index to be 5, from
> mfi_sw_if_index==7. I'm a bit out of my depth here, so I'll have to defer
> to others who are more knowledgeable.
>
> groet,
> Pim
>
> On Mon, Jan 17, 2022 at 10:25 AM Pim van Pelt  wrote:
>
>> Hoi,
>>
>> I have seen that message, but it is not related to the Linux CP
>> plugin, and it seems benign -- that is to say, Linux CP and VPP work just
>> fine even though the error is emitted.
>> Without Linux CP enabled, the same message appears when adding an IP
>> address to a sub-int. I didn't look in to it very long, but the error is
>> emitted in src/vnet/interface.c:1583 for
>> function vnet_hw_interface_add_del_mac_address() which occurs only in a few
>> places:
>>
>> src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
>> (lm->vnet_main,
>> src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
>> (lm->vnet_main,
>> src/plugins/vrrp/vrrp.c:  error =
>> vnet_hw_interface_add_del_mac_address
>> src/vnet/interface_api.c:  error = vnet_hw_interface_add_del_mac_address
>> (vnm, hi->hw_if_index,
>> src/vnet/mfib/mfib_itf.c:vnet_hw_interface_add_del_mac_address
>> (vnet_get_main(),
>> src/vnet/bonding/device.c:error =
>> vnet_hw_interface_add_del_mac_address (vnm, s_hi->hw_if_index,
>> src/vnet/bonding/device.c:  vnet_hw_in

Re: [vpp-dev] VPP IPSec Related Doubts

2022-01-17 Thread Hrishikesh Karanjikar

Hi Juraj,

Thanks for your reply.
I was able to get the things working with new commands.

Thanks,
Hrishikesh

On Mon, Jan 17, 2022 at 7:02 PM Juraj Linkeš 
wrote:

> Hi Hrishikesh,
>
>
>
> The API has changed, try without the hyphen:
>
> ipsec sa add 10 spi 1000 esp tunnel src 192.168.1.1 tunnel dst 192.168.1.2
> crypto-key 4339314b55523947594d6d3547666b45 crypto-alg aes-cbc-128
> integ-key 4339314b55523947594d6d3547666b45 integ-alg sha1-96
>
>
>
> Regards,
>
> Juraj
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Hrishikesh
> Karanjikar
> *Sent:* Thursday, December 16, 2021 10:45 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] VPP IPSec Related Doubts
>
>
>
> Hi All,
>
>
>
> I am trying to get following setup working,
>
>
>
>
> https://www.intel.com/content/www/us/en/developer/articles/guide/get-started-with-ipsec-acceleration-in-the-fdio-vpp-project.html
>
>
>
> The commands in above setup are as follows,
>
> =
>
> set int ip address TenGigabitEthernet6/0/0 192.168.30.30/24
> set int promiscuous on TenGigabitEthernet6/0/0
> set int ip address TenGigabitEthernet6/0/1 192.168.30.31/24
> set int promiscuous on TenGigabitEthernet6/0/1
>
> ipsec spd add 1
> set interface ipsec spd TenGigabitEthernet6/0/1 1
> ipsec sa add 10 spi 1000 esp tunnel-src 192.168.1.1 tunnel-dst 192.168.1.2
> crypto-key 4339314b55523947594d6d3547666b45 crypto-alg aes-cbc-128
> integ-key 4339314b55523947594d6d3547666b45 integ-alg sha1-96
> ipsec policy add spd 1 outbound priority 100 action protect sa 10
> local-ip-range 192.168.20.0-192.168.20.255 remote-ip-range
> 192.168.40.0-192.168.40.255
> ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass
>
> ip route add 192.168.40.40/32 via 192.168.1.2 TenGigabitEthernet6/0/1
> set ip arp TenGigabitEthernet6/0/1 192.168.1.2 90:e2:ba:50:8f:19
>
> set int state TenGigabitEthernet6/0/0 up
> set int state TenGigabitEthernet6/0/1 up
>
> =
>
>
> However, a few commands in the setup are failing.
>
> e.g.
>
> DBGvpp# ipsec sa add 10 spi 1000 esp tunnel-src 192.168.1.1 tunnel-dst
> 192.168.1.2 crypto-key 4339314b55523947594d6d3547666b45 crypto-alg
> aes-cbc-128 integ-key 4339314b55523947594d6d3547666b45 integ-alg sha1-96
> ipsec sa: parse error: '-src 192.168.1.1 tunnel-dst 19...'
>
>
>
> Can anybody guide me on how to go about this?
>
>
>
> --
>
>
> Thanks and Regards,
> Hrishikesh Karanjikar
>


-- 

Regards,
Hrishikesh Karanjikar

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20736): https://lists.fd.io/g/vpp-dev/message/20736
Mute This Topic: https://lists.fd.io/mt/87764016/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] linux-cp TAP MTU show issue

2022-01-17 Thread Pim van Pelt

Hoi Petr, others,

Petr, in case you were interested to take a look -- I became a bit less
lazy and started VPP in a debugger, and added a breakpoint in the
vnet_hw_interface_add_del_mac_address function.


DBGvpp# create sub HundredGigabitEthernet15/0/0  10

HundredGigabitEthernet15/0/0.10

DBGvpp# show int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS)
Counter  Count
GigabitEthernet5/0/0  1 down 9000/0/0/0
GigabitEthernet5/0/1  2 down 9000/0/0/0
GigabitEthernet5/0/2  3 down 9000/0/0/0
GigabitEthernet5/0/3  4 down 9000/0/0/0
HundredGigabitEthernet15/0/0  5 down 9000/0/0/0
HundredGigabitEthernet15/0/0.10   7 down  0/0/0/0
HundredGigabitEthernet15/0/1  6 down 9000/0/0/0
local00 down  0/0/0/0
DBGvpp# set interface ip address HundredGigabitEthernet15/0/0.10
192.0.2.1/30



This is the call stack:
#0  vnet_hw_interface_add_del_mac_address (vnm=0x77f42ec0 ,
hw_if_index=0, mac_address=0x7fff513e87f0 "\001", is_add=1 '\001')
at /home/pim/src/vpp/src/vnet/interface.c:1580
#1  0x777a8b46 in mfib_itf_mac_add_del (itf=0x7fff9c6710c0,
pfx=0x7fff97c69bcc, add=1) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:167
#2  0x777a8ad2 in mfib_itf_mac_add (itf=0x7fff9c6710c0,
pfx=0x7fff97c69bcc) at /home/pim/src/vpp/src/vnet/mfib/mfib_itf.c:176
#3  0x777ac6a5 in mfib_entry_path_update (mfib_entry_index=1,
source=MFIB_SOURCE_SPECIAL, rpaths=0x7fff97e0ceb0)
at /home/pim/src/vpp/src/vnet/mfib/mfib_entry.c:1070
#4  0x777b353c in mfib_table_entry_paths_update_i (fib_index=0,
prefix=0x77d096e0 , source=MFIB_SOURCE_SPECIAL,
entry_flags=MFIB_ENTRY_FLAG_NONE, rpaths=0x7fff97e0ceb0) at
/home/pim/src/vpp/src/vnet/mfib/mfib_table.c:319
#5  0x777b31f9 in mfib_table_entry_path_update (fib_index=0,
prefix=0x77d096e0 , source=MFIB_SOURCE_SPECIAL,
entry_flags=MFIB_ENTRY_FLAG_NONE, rpath=0x7fff513e89c0) at
/home/pim/src/vpp/src/vnet/mfib/mfib_table.c:337
#6  0x7779bbd1 in ip4_mfib_interface_enable_disable (sw_if_index=7,
is_enable=1) at /home/pim/src/vpp/src/vnet/mfib/ip4_mfib.c:158
#7  0x7720aeec in ip4_add_del_interface_address_internal
(vm=0x7fff96800680, sw_if_index=7, address=0x7fff513e8dd8,
address_length=30,
is_del=0) at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:807
#8  0x7720a1f1 in ip4_add_del_interface_address (vm=0x7fff96800680,
sw_if_index=7, address=0x7fff513e8dd8, address_length=30, is_del=0)
at /home/pim/src/vpp/src/vnet/ip/ip4_forward.c:839
#9  0x772017e5 in add_del_ip_address (vm=0x7fff96800680,
input=0x7fff513e9e40, cmd=0x7fff97b5c518)
at /home/pim/src/vpp/src/vnet/ip/ip46_cli.c:171

in mfib_itf_mac_add_del(), itf->mfi_sw_if_index==7 (this is the index of
the just created sub-int), the lookup in line 166 yields si->hw_if_index ==
0, which is then passed on to the vnet_hw_interface_add_del_mac_address()
call, provoking the error, because I think it references phy sw index 0
(interface local0)?
DBGvpp# show mfib interface
mFIB interfaces::
0@ HundredGigabitEthernet15/0/0.10: Accept,
1@ HundredGigabitEthernet15/0/0.10: Accept,

Curiously, I would've expected si->hw_if_index to be 5, from
mfi_sw_if_index==7. I'm a bit out of my depth here, so I'll have to defer
to others who are more knowledgeable.

groet,
Pim

On Mon, Jan 17, 2022 at 10:25 AM Pim van Pelt  wrote:

> Hoi,
>
> I have seen that message, but it is not related to the Linux CP
> plugin, and it seems benign -- that is to say, Linux CP and VPP work just
> fine even though the error is emitted.
> Without Linux CP enabled, the same message appears when adding an IP
> address to a sub-int. I didn't look in to it very long, but the error is
> emitted in src/vnet/interface.c:1583 for
> function vnet_hw_interface_add_del_mac_address() which occurs only in a few
> places:
>
> src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
> (lm->vnet_main,
> src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
> (lm->vnet_main,
> src/plugins/vrrp/vrrp.c:  error = vnet_hw_interface_add_del_mac_address
> src/vnet/interface_api.c:  error = vnet_hw_interface_add_del_mac_address
> (vnm, hi->hw_if_index,
> src/vnet/mfib/mfib_itf.c:vnet_hw_interface_add_del_mac_address
> (vnet_get_main(),
> src/vnet/bonding/device.c:error =
> vnet_hw_interface_add_del_mac_address (vnm, s_hi->hw_if_index,
> src/vnet/bonding/device.c:  vnet_hw_interface_add_del_mac_address
> (vnm, s_hi->hw_if_index,
> src/vnet/bonding/cli.c:vnet_hw_interface_add_del_mac_address (vnm,
> s_hwif->hw_if_index,
> src/vnet/interface_cli.c:vnet_hw_interface_add_del_mac_address (vnm,
> si->hw_if_index, mac, is_add);
>
> If you're curious, you could take a look at these call sites. One other
> place you might look is ip6_add_del_interface_address()
> and

Re: [vpp-dev] VPP IPSec Related Doubts

2022-01-17 Thread Juraj Linkeš

Hi Hrishikesh,

The API has changed, try without the hyphen:
ipsec sa add 10 spi 1000 esp tunnel src 192.168.1.1 tunnel dst 192.168.1.2 
crypto-key 4339314b55523947594d6d3547666b45 crypto-alg aes-cbc-128 integ-key 
4339314b55523947594d6d3547666b45 integ-alg sha1-96

Regards,
Juraj

From: vpp-dev@lists.fd.io  On Behalf Of Hrishikesh 
Karanjikar
Sent: Thursday, December 16, 2021 10:45 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP IPSec Related Doubts

Hi All,

I am trying to get following setup working,

https://www.intel.com/content/www/us/en/developer/articles/guide/get-started-with-ipsec-acceleration-in-the-fdio-vpp-project.html

The commands in above setup are as follows,
=
set int ip address TenGigabitEthernet6/0/0 
192.168.30.30/24
set int promiscuous on TenGigabitEthernet6/0/0
set int ip address TenGigabitEthernet6/0/1 
192.168.30.31/24
set int promiscuous on TenGigabitEthernet6/0/1

ipsec spd add 1
set interface ipsec spd TenGigabitEthernet6/0/1 1
ipsec sa add 10 spi 1000 esp tunnel-src 192.168.1.1 tunnel-dst 192.168.1.2 
crypto-key 4339314b55523947594d6d3547666b45 crypto-alg aes-cbc-128 integ-key 
4339314b55523947594d6d3547666b45 integ-alg sha1-96
ipsec policy add spd 1 outbound priority 100 action protect sa 10 
local-ip-range 192.168.20.0-192.168.20.255 remote-ip-range 
192.168.40.0-192.168.40.255
ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass

ip route add 192.168.40.40/32 via 192.168.1.2 
TenGigabitEthernet6/0/1
set ip arp TenGigabitEthernet6/0/1 192.168.1.2 90:e2:ba:50:8f:19

set int state TenGigabitEthernet6/0/0 up
set int state TenGigabitEthernet6/0/1 up
=

However, a few commands in the setup are failing.
e.g.
DBGvpp# ipsec sa add 10 spi 1000 esp tunnel-src 192.168.1.1 tunnel-dst 
192.168.1.2 crypto-key 4339314b55523947594d6d3547666b45 crypto-alg aes-cbc-128 
integ-key 4339314b55523947594d6d3547666b45 integ-alg sha1-96
ipsec sa: parse error: '-src 192.168.1.1 tunnel-dst 19...'

Can anybody guide me on how to go about this?

--

Thanks and Regards,
Hrishikesh Karanjikar

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20734): https://lists.fd.io/g/vpp-dev/message/20734
Mute This Topic: https://lists.fd.io/mt/87764016/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] vlan tag rewrite failure on traffic (other side is a kernel vlan interface)

2022-01-17 Thread Laszlo Király

Hello,

It turned out that the problem was caused by the checksum offload set on 
virtual interfaces on the sender side.
The workaround is to set the following on host A:
docker exec rvm-tester ethtool -K eth0 tx off

So, it's definitely NOT a vpp fault. Sorry for bothering you with this issue.

--
Regards,
Laszlo Kiraly


From: Laszlo Király
Sent: Tuesday, January 11, 2022 4:31 PM
To: vpp-dev@lists.fd.io 
Subject: vlan tag rewrite failure on traffic (other side is a kernel vlan 
interface)

Hello,

I am facing a problem using VLAN tag rewrite functionality on VPP.

The communication between a kernel vlan interface and a VPP VLAN sub-interface 
fails. The ICMP is working but TCP/UDP packets are dropped by the kernel (just 
one side - see the test description)

Find attached the detailed topology, test details, the reproduction 
instructions, vpp version and 'show' commands output and tcpdump capture files 
as well.

Please advise me with the way forward:
- It can be a configuration problem - what should be changed?
- Might be a fault in kernel checksum (has a low chance, but can happen)
- Can be a fault in VPP tag rewrite - can I raise a ticket? Do you need 
additional information?


1. Network Topology
 See attached file: topo.txt

2. Test Description

The 'Host A' should reach the 'Host B' by eth1.100 and respectively veth1 
interfaces. The 'ping' works, but when trying to establish a TCP connection 
(ncat/iperf) the connection fails.
2/A Client is on 'Host A'
Based on captured trace the SYN arrives to veth1 but it is dropped and does 
not reach the server listening on 'host B', 'orange' nw namespace.

2/B Client is on 'Host B', 'orange' namespace
Based on trace the SYN is received and replied by the server on 'Host A'. 
The SYN ACK can be seen in tcpdump, but dropped by the kernel.

Seems that the case when VPP adding VLAN tag to the packet is working but when 
removing the VLAN tag from the packet the kernel drops the packet.

Based on kernel statistics the TcpInCsumErrors counter increasing, however the 
VLAN is on ethernet level.

3. Reproduction Steps

See attached file: test-vtr-tcpfailure.txt

4. VPP Version and 'show' Command Outputs

See attached file: test-vtr-cmds.txt

5. Capture Files

Tcpdump captures:
ext-in-tcp-failure-sut-eth1.pcap
ext-in-tcp-failure-sut-veth1.pcap
ext-in-tcp-failure-tester.pcap
out-tcp-failure-sut-eth1.pcap
out-tcp-failure-sut-veth1.pcap
out-tcp-failure-tester.pcap

--
Laszlo Kiraly

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

[vpp-dev]: Segmentation fault in mspace_is_heap_object

2022-01-17 Thread Rajith PR via lists.fd.io

Hi All,

We are facing a random crash during the scale of MPLS tunnels(8000 mpls
tunnels). The crash has been observed multiple times and the call stack is
the same.
During the worker thread crash the main thread has executed the following
lines of code(between the barrier sync and release), please provide us
inputs to debug this issue.


  vlib_worker_thread_barrier_sync (vm);
  ret_val = rtb_vpp_route_rpath_create(route_mapping, &rpath,
RTB_VPP_ADD);
  if (RTB_VPP_SUCCESS != ret_val) {
  goto Exit;
  }
  vec_add1(rpaths, rpath);
  tunnel_sw_if_index = vnet_mpls_tunnel_create(1, 0, NULL);
  vnet_mpls_tunnel_path_add(tunnel_sw_if_index, rpaths);
  vlib_worker_thread_barrier_release (vm);

VPP Version : 20.09

BT:

Thread 3 (Thread 0x7fcf87fff700 (LWP 22778)):
#0  0x7fd04613a492 in __GI___waitpid (pid=25786,
stat_loc=stat_loc@entry=0x7fd02514b9a8,
options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7fd0460a5177 in do_system (line=line@entry=0x7fd02514bb30
"/usr/local/bin/rtb-dump-core.sh '22729' 'fibd'") at
../sysdeps/posix/system.c:149
#2












*  0x7fd0460a555a in __libc_system (line=line@entry=0x7fd02514bb30
"/usr/local/bin/rtb-dump-core.sh '22729' 'fibd'") at
../sysdeps/posix/system.c:185#3  0x7fd04667105d in bd_signal_handler_cb
(signo=11) at
/development/rtbrick-infrastructure/code/bd/src/bdinfra/bd.c:753#4
 0x7fd037b4b73f in rtb_bd_signal_handler (signo=11) at
/development/libvpp/src/vlib/unix/main.c:80#5  0x7fd037b4bba2 in
unix_signal_handler (signum=11, si=0x7fd02514bfb0, uc=0x7fd02514be80) at
/development/libvpp/src/vlib/unix/main.c:180#6  #7
 0x7fd0372f1389 in mspace_is_heap_object (msp=0x7fd008ec3010,
p=0x7fd0264c66c8) at /development/libvpp/src/vppinfra/dlmalloc.c:4134#8
 0x7fd037b1b482 in clib_mem_is_heap_object (p=0x7fd0264c66c8) at
/development/libvpp/src/vppinfra/mem.h:211#9  0x7fd037b0aaa6 in
_vec_resize_inline (v=0x7fd0264c66d0, length_increment=1, data_bytes=59368,
header_bytes=0, data_align=8, numa_id=255)at
/development/libvpp/src/vppinfra/vec.h:154#10 0x7fd037b15fbe in
vlib_worker_thread_node_refork () at
/development/libvpp/src/vlib/threads.c:1133#11 0x7fd037ac8196 in
vlib_worker_thread_barrier_check () at
/development/libvpp/src/vlib/threads.h:482#12 0x7fd037ac259e in
vlib_main_or_worker_loop (vm=0x7fd00c58ac40, is_main=0) at
/development/libvpp/src/vlib/main.c:1788#13 0x7fd037ac1db7 in
vlib_worker_loop (vm=0x7fd00c58ac40) at
/development/libvpp/src/vlib/main.c:2008#14 0x7fd037b19b1a in
vlib_worker_thread_fn* (arg=0x7fd00925e700) at
/development/libvpp/src/vlib/threads.c:1862
#15 0x7fd037340c34 in clib_calljmp () at
/development/libvpp/src/vppinfra/longjmp.S:123
#16 0x7fcf87ffed00 in ?? ()
#17 0x7fd037b11cc3 in vlib_worker_thread_bootstrap_fn
(arg=0x7fd00925e700) at /development/libvpp/src/vlib/threads.c:585
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0x7fcf8cbff700 (LWP 22777)):
#0  0x7fd037ac81c6 in vlib_worker_thread_barrier_check () at
/development/libvpp/src/vlib/threads.h:485
#1  0x7fd037ac259e in vlib_main_or_worker_loop (vm=0x7fd024530e40,
is_main=0) at /development/libvpp/src/vlib/main.c:1788
#2  0x7fd037ac1db7 in vlib_worker_loop (vm=0x7fd024530e40) at
/development/libvpp/src/vlib/main.c:2008
#3  0x7fd037b19b1a in vlib_worker_thread_fn (arg=0x7fd00925e600) at
/development/libvpp/src/vlib/threads.c:1862
#4  0x7fd037340c34 in clib_calljmp () at
/development/libvpp/src/vppinfra/longjmp.S:123
#5  0x7fcf8cbfed00 in ?? ()
#6  0x7fd037b11cc3 in vlib_worker_thread_bootstrap_fn
(arg=0x7fd00925e600) at /development/libvpp/src/vlib/threads.c:585
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 0x7fd046adb400 (LWP 22729)):
#0  vlib_time_now (vm=0x7fd037d81c40 ) at
/development/libvpp/src/vlib/main.h:345
#1  0x7fd037b1863c in vlib_worker_thread_barrier_release
(vm=0x7fd037d81c40 ) at
/development/libvpp/src/vlib/threads.c:1631
#2  0x7fd039719985 in rtb_vpp_l2_xconnect_route_add_handle
(route_mapping=0x7fcff329d220) at
/development/libvpp/src/vpp/rtbrick/rtb_vpp_l2_xconnect.c:97
#3  0x7fd03971a229 in rtb_vpp_l2_xconnect_route_handle
(route_mapping=0x7fcff329d220, action=0 '\000') at
/development/libvpp/src/vpp/rtbrick/rtb_vpp_l2_xconnect.c:179
#4  0x7fd0396692a7 in rtb_vpp_route_mapping_process
(route_mapping=0x7fcff329d220, action=0 '\000') at
/development/libvpp/src/vpp/rtbrick/rtb_vpp_route.c:258
#5  0x7fd03966cbd4 in rtb_vpp_adj_adjacency_route_handle
(adj_api_out=0x7fcff329d410, action=0 '\000') at
/development/libvpp/src/vpp/rtbrick/rtb_vpp_adj.c:247
#6  0x7fd03966cd30 in rtb_vpp_adj_api_out_process
(table=0x56425216b120, object=0x56425cfa6b30, action=0 '\000') at
/development/libvpp/src/vpp/rtbrick/rtb_vpp_adj.c:283
#7  0x7fd03966cdaf in rtb_vpp_adj_api_out_add_cb (tab

Re: [vpp-dev] linux-cp TAP MTU show issue

2022-01-17 Thread Pim van Pelt

Hoi,

I have seen that message, but it is not related to the Linux CP plugin, and
it seems benign -- that is to say, Linux CP and VPP work just fine even
though the error is emitted.
Without Linux CP enabled, the same message appears when adding an IP
address to a sub-int. I didn't look in to it very long, but the error is
emitted in src/vnet/interface.c:1583 for
function vnet_hw_interface_add_del_mac_address() which occurs only in a few
places:

src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
(lm->vnet_main,
src/plugins/lldp/lldp_cli.c:vnet_hw_interface_add_del_mac_address
(lm->vnet_main,
src/plugins/vrrp/vrrp.c:  error = vnet_hw_interface_add_del_mac_address
src/vnet/interface_api.c:  error = vnet_hw_interface_add_del_mac_address
(vnm, hi->hw_if_index,
src/vnet/mfib/mfib_itf.c:vnet_hw_interface_add_del_mac_address
(vnet_get_main(),
src/vnet/bonding/device.c:error = vnet_hw_interface_add_del_mac_address
(vnm, s_hi->hw_if_index,
src/vnet/bonding/device.c:  vnet_hw_interface_add_del_mac_address
(vnm, s_hi->hw_if_index,
src/vnet/bonding/cli.c:vnet_hw_interface_add_del_mac_address (vnm,
s_hwif->hw_if_index,
src/vnet/interface_cli.c:vnet_hw_interface_add_del_mac_address (vnm,
si->hw_if_index, mac, is_add);

If you're curious, you could take a look at these call sites. One other
place you might look is ip6_add_del_interface_address()
and ip4_add_del_interface_address() which are the functions that get called
when you issue the CLI 'set interface ip address' command.

But it would also be okay to ignore the error for now -- maybe others have
a recollection of how vnet_hw_interface_add_del_mac_address() does its
business.

groet,
Pim

On Mon, Jan 17, 2022 at 9:27 AM Petr Boltík  wrote:

> Hello,
>
> did you notice this error message from systemctl?
>
> Message from systemctl status vpp-dataplane:
> vnet[2526]: interface: hw_add_del_mac_address:
> vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
> supported for interface index 0
> Jan 17 03:16:05 stredni vnet[2526]: interface: hw_add_del_mac_address:
> vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
> supported for interface index 0
>
> Vpp run in separated netns. Latest vpp v22.02-rc0~503-gf8dd9d8af. Message
> is related to ip address configuration on vlan subinterface.
>
> Config below...
>
> Regards Petr
>
> #!/bin/sh
> vppctl lcp default netns controlplane
> vppctl lcp lcp-sync on
> vppctl lcp lcp-auto-subint on
> vppctl set interface mtu packet 1500 enp3s0
> vppctl lcp create enp3s0 host-if enp3s0
> vppctl set interface state enp3s0 up
> vppctl create sub enp3s0 10
> vppctl set interface ip address enp3s0.10 192.168.18.1/24
> vppctl set interface state enp3s0.10 up
>
>
> pá 14. 1. 2022 v 17:42 odesílatel Petr Boltík via lists.fd.io
>  napsal:
>
>> Hi,
>> Yes, I have tested the latest code that includes
>> https://gerrit.fd.io/r/c/vpp/+/33709. Test:
>> "lcp lcp-sync on" => everything work fine
>> "lcp lcp-sync off" => issue appears
>>
>> Here is a video with an example
>> https://youtu.be/wwyXyVilvOk
>>
>> Regards
>> Petr
>>
>> pá 14. 1. 2022 v 16:59 odesílatel Pim van Pelt  napsal:
>>
>>> Hoi Petr,
>>>
>>> We merged a relevant VPP -> Linux interface sync change in
>>> https://gerrit.fd.io/r/c/vpp/+/33709 just this week.
>>> The code that does this sync is in lcp_interface_sync.c:100
>>> and lcp_interface.c:1004.
>>> Does your build include that code, and did you issue "lcp lcp-sync on" ?
>>>
>>>
>>> On Fri, Jan 14, 2022 at 3:34 PM Petr Boltík 
>>> wrote:
>>>
 Hello,
 I have found a cosmetic issue with a linux-cp TAP device (tested both
 plugins - original and patched linux-cp 31122 ). If you try to add multiple
 LCP TAP interfaces, sometimes there is bug in "vppctl show interface"
 output. MTU at the TAP is randomly shown incorrectly like:
 tap10 11 up   4/0/0/0
 tap18 19 up  1500/0/0/0
 tap26 27 up  9216/0/0/0

 MTU 1500 pass to the control plane successfully and MTU inside netns is
 correct. Test script below, you may run it a few times to see an issue. I
 have run it inside netns "controlplane". Tested 21.10 and
 22.02-rc0~347-g5dec92de6.

 Regards
 Petr

 #!/bin/bash
 vppctl lcp default netns controlplane
 for i in $(seq 1 30); do
   vppctl create loopback interface instance $i
   vppctl set interface mtu packet 1500 loop$i
   vppctl lcp create loop$i host-if br$i
   vppctl set interface state loop$i up
 done





>>>
>>> --
>>> Pim van Pelt 
>>> PBVP1-RIPE - http://www.ipng.nl/
>>>
>>
>> 
>>
>>

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20731): https://lists.fd.io/g/vpp-dev/message/20731
Mute This Topic: https://lists

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

2022-01-17 Thread Amit Mehra

Thanks Neale for the response.

We are trying to simulate L3VPN usecase and want to maintain counters per 
FEC(on both PE and P nodes).

Yes, we can achieve label swap/pop without tunnel interface too but that way we 
are not maintaining per FEC counters. As per my understanding, with tunnels, we 
can have counters per FEC.

I have few follow-up questions based on your responses
1) Are tunnel interfaces meant only for having statistics per FEC or are there 
any other usecase for creating mpls tunnel? In other words, we can achieve 
label encapsulation, label swap/pop operations without tunnel too then what's 
the need of having a tunnel?

2) As per the sample configuration of L3VPN given in 
https://wiki.fd.io/view/VPP/MPLS_FIB, tunnel interface is not considered. Any 
reason why tunnel interface is not considered for realizing L3VPN ? Does it 
have any other implication (if considered for L3VPN) or we can configure L3VPN 
even with tunnel interface (on both PE and P devices) too and it would be 
another alternative way?

Regards
Amit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20730): https://lists.fd.io/g/vpp-dev/message/20730
Mute This Topic: https://lists.fd.io/mt/88418846/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] linux-cp TAP MTU show issue

2022-01-17 Thread Petr Boltík

Hello,

did you notice this error message from systemctl?

Message from systemctl status vpp-dataplane:
vnet[2526]: interface: hw_add_del_mac_address:
vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
supported for interface index 0
Jan 17 03:16:05 stredni vnet[2526]: interface: hw_add_del_mac_address:
vnet_hw_interface_add_del_mac_address: Secondary MAC Addresses not
supported for interface index 0

Vpp run in separated netns. Latest vpp v22.02-rc0~503-gf8dd9d8af. Message
is related to ip address configuration on vlan subinterface.

Config below...

Regards Petr

#!/bin/sh
vppctl lcp default netns controlplane
vppctl lcp lcp-sync on
vppctl lcp lcp-auto-subint on
vppctl set interface mtu packet 1500 enp3s0
vppctl lcp create enp3s0 host-if enp3s0
vppctl set interface state enp3s0 up
vppctl create sub enp3s0 10
vppctl set interface ip address enp3s0.10 192.168.18.1/24
vppctl set interface state enp3s0.10 up


pá 14. 1. 2022 v 17:42 odesílatel Petr Boltík via lists.fd.io  napsal:

> Hi,
> Yes, I have tested the latest code that includes
> https://gerrit.fd.io/r/c/vpp/+/33709. Test:
> "lcp lcp-sync on" => everything work fine
> "lcp lcp-sync off" => issue appears
>
> Here is a video with an example
> https://youtu.be/wwyXyVilvOk
>
> Regards
> Petr
>
> pá 14. 1. 2022 v 16:59 odesílatel Pim van Pelt  napsal:
>
>> Hoi Petr,
>>
>> We merged a relevant VPP -> Linux interface sync change in
>> https://gerrit.fd.io/r/c/vpp/+/33709 just this week.
>> The code that does this sync is in lcp_interface_sync.c:100
>> and lcp_interface.c:1004.
>> Does your build include that code, and did you issue "lcp lcp-sync on" ?
>>
>>
>> On Fri, Jan 14, 2022 at 3:34 PM Petr Boltík 
>> wrote:
>>
>>> Hello,
>>> I have found a cosmetic issue with a linux-cp TAP device (tested both
>>> plugins - original and patched linux-cp 31122 ). If you try to add multiple
>>> LCP TAP interfaces, sometimes there is bug in "vppctl show interface"
>>> output. MTU at the TAP is randomly shown incorrectly like:
>>> tap10 11 up   4/0/0/0
>>> tap18 19 up  1500/0/0/0
>>> tap26 27 up  9216/0/0/0
>>>
>>> MTU 1500 pass to the control plane successfully and MTU inside netns is
>>> correct. Test script below, you may run it a few times to see an issue. I
>>> have run it inside netns "controlplane". Tested 21.10 and
>>> 22.02-rc0~347-g5dec92de6.
>>>
>>> Regards
>>> Petr
>>>
>>> #!/bin/bash
>>> vppctl lcp default netns controlplane
>>> for i in $(seq 1 30); do
>>>   vppctl create loopback interface instance $i
>>>   vppctl set interface mtu packet 1500 loop$i
>>>   vppctl lcp create loop$i host-if br$i
>>>   vppctl set interface state loop$i up
>>> done
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Pim van Pelt 
>> PBVP1-RIPE - http://www.ipng.nl/
>>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20729): https://lists.fd.io/g/vpp-dev/message/20729
Mute This Topic: https://lists.fd.io/mt/88421552/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] linux-cp + nat44 possible?

Re: [vpp-dev] linux-cp + nat44 possible?

Re: [vpp-dev] linux-cp + nat44 possible?

[vpp-dev] linux-cp + nat44 possible?

Re: [vpp-dev] linux-cp TAP MTU show issue

Re: [vpp-dev] VPP IPSec Related Doubts

Re: [vpp-dev] linux-cp TAP MTU show issue

Re: [vpp-dev] VPP IPSec Related Doubts

Re: [vpp-dev] vlan tag rewrite failure on traffic (other side is a kernel vlan interface)

[vpp-dev]: Segmentation fault in mspace_is_heap_object

Re: [vpp-dev] linux-cp TAP MTU show issue

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

Re: [vpp-dev] linux-cp TAP MTU show issue

13 matches

Site Navigation

Mail list logo

Footer information