Re: [vpp-dev] vpp-verify-master-centos7 jobs failing
Status update: After much investigation and a tweak to the Nomad Plugin configuration (increasing CPU allocation for the centos7 executors), it seemed that the issue went away. Several patches completed verification, but there was another early termination of a vpp-veriy-master-centos7 job. There has also been wrongful termination of vpp-verify-master-clang & vpp-verify-master-ubuntu1804 jobs identified while investigating -1 Verify votes. In order to address another theory, I have requested two additional configuration changes via the LF support page [0]: 1. Increase in CPU allocation for ubuntu1804 executors 2. Increase in idle termination timeout for both ubuntu1804 & centos7 to 60 seconds (from 10 sec) I've also seen Nomad client heartbeat timeouts on some of the clients, which in theory may cause job termination. Google-fu on this topic indicates that either network issues or cpu overload could cause heartbeat failures. I'm going to reduce the load on the primary Nomad server machines by shutting down the Nomad client agents on those machines although I don't think that they're heavily loaded. I'll continue monitoring the situation to see if these actually fix the problem. In the meantime, if your verify jobs fail and the logs indicate that the job was killed (search for "Killed" case-sensitive), please let me know and Reply to the gerrit change with the comment "recheck". Thank you for your patience, -daw- [0] https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19676 On 5/8/20 1:13 PM, Dave Wallace via lists.fd.io wrote: Folks, I'm working with Vanessa on the LF Infra team to troubleshoot and fix the vpp-verify-master-centos7 jobs failing. Please be patient as we get this issue resolved. Thanks, -daw- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16287): https://lists.fd.io/g/vpp-dev/message/16287 Mute This Topic: https://lists.fd.io/mt/74078138/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Use OSS-Fuzz, and get upto 20K USD reward
Hi, vpp developers, I think someone may be interested in the following. If you have an ideal integration of google's OSS-Fuzz with vpp, you will get upto $20,000 for an ideal integration. See more details, and how to get started: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16286): https://lists.fd.io/g/vpp-dev/message/16286 Mute This Topic: https://lists.fd.io/mt/74079776/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vpp-verify-master-centos7 jobs failing
Folks, I'm working with Vanessa on the LF Infra team to troubleshoot and fix the vpp-verify-master-centos7 jobs failing. Please be patient as we get this issue resolved. Thanks, -daw- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16285): https://lists.fd.io/g/vpp-dev/message/16285 Mute This Topic: https://lists.fd.io/mt/74078138/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] Assertion failure in nat_get_vlib_main() in snat_init()
I merged Ole's patch a minute ago. Again, thanks for the report...
Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Elias Rudberg
Sent: Friday, May 8, 2020 5:30 AM
To: otr...@employees.org
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Assertion failure in nat_get_vlib_main() in snat_init()
Hi Ole,
Yes, that fixes it!
With that patch my NAT test works, no more assertion failures.
/ Elias
On Fri, 2020-05-08 at 10:06 +0200, Ole Troan wrote:
> Hi Elias,
>
> Thanks for finding that one.
> Can you verify that this patch fixes it:
> https://gerrit.fd.io/r/c/vpp/+/26951 nat: fix per thread data
> vlib_main_t usage take 2 [NEW]
>
> Best regards,
> Ole
>
> > On 7 May 2020, at 22:57, Elias Rudberg
> > wrote:
> >
> > Hello,
> >
> > With the current master branch (def78344) we now get an assertion
> > failure on startup, here:
> >
> > (gdb) bt
> > #0 __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> > #1 0x7462e801 in __GI_abort () at abort.c:79
> > #2 0x004071f3 in os_panic ()
> >at vpp/src/vpp/vnet/main.c:366
> > #3 0x7550d7d9 in debugger ()
> >at vpp/src/vppinfra/error.c:84
> > #4 0x7550d557 in _clib_error (how_to_die=2,
> > function_name=0x0, line_number=0,
> >fmt=0x7fffacbc0310 "%s:%d (%s) assertion `%s' fails")
> >at vpp/src/vppinfra/error.c:143
> > #5 0x7fffacac659e in nat_get_vlib_main (thread_index=4)
> >at vpp/src/plugins/nat/nat.c:2557
> > #6 0x7fffacabd7a5 in snat_init (vm=0x7639b980
> > )
> >at vpp/src/plugins/nat/nat.c:2685
> > #7 0x760b9f66 in call_init_exit_functions_internal
> > (vm=0x7639b980 ,
> >headp=0x7639bfa8 , call_once=1,
> > do_sort=1)
> >at vpp/src/vlib/init.c:350
> > #8 0x760b9e88 in vlib_call_init_exit_functions
> > (vm=0x7639b980 ,
> >headp=0x7639bfa8 , call_once=1)
> >at vpp/src/vlib/init.c:364
> > #9 0x760ba011 in vlib_call_all_init_functions
> > (vm=0x7639b980 )
> >at vpp/src/vlib/init.c:386
> > #10 0x760df1f8 in vlib_main (vm=0x7639b980
> > , input=0x7fffb4b2afa8)
> >at vpp/src/vlib/main.c:2171
> > #11 0x76166405 in thread0 (arg=140737324366208)
> >at vpp/src/vlib/unix/main.c:658
> > #12 0x75531954 in clib_calljmp ()
> >at vpp/src/vppinfra/longjmp.S:123
> > #13 0x7fffcf30 in ?? ()
> > #14 0x76165f97 in vlib_unix_main (argc=57, argv=0x71d520)
> >at vpp/src/vlib/unix/main.c:730
> > #15 0x004068d8 in main (argc=57, argv=0x71d520)
> >at vpp/src/vpp/vnet/main.c:291
> >
> > The code looks like this (this part was added in a recent commit it
> > seems):
> >
> > always_inline vlib_main_t *
> > nat_get_vlib_main (u32 thread_index) { vlib_main_t *vm; vm =
> > vlib_mains[thread_index]; ASSERT (vm); return vm; }
> >
> > So it is looking at vlib_mains[thread_index] but that is NULL,
> > apparently.
> >
> > Since this happens at startup, could it be that vlib_mains has not
> > been initialized yet, it is too early to try to access it?
> >
> > Is vlib_mains[thread_index] supposed to be initialized by the time
> > when
> > vlib_call_all_init_functions() runs?
> >
> > Best regards,
> > Elias
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16284): https://lists.fd.io/g/vpp-dev/message/16284
Mute This Topic: https://lists.fd.io/mt/74060018/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 tunnel interfaces?
On May 8, 2020, at 3:57 AM, Neale Ranns via lists.fd.io wrote: > > > > From: on behalf of Christian Hopps > Date: Thursday 7 May 2020 at 23:27 > To: "Neale Ranns (nranns)" > Cc: Christian Hopps , vpp-dev > Subject: Re: [vpp-dev] IPsec tunnel interfaces? > > > > > On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote: > > > > > > Hi Chris, > > > > On 07/05/2020 16:55, "Christian Hopps" wrote: > > > > > > > >> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote: > >> > >> > >> Hi Chris, > >> > >> They were replaced by ipip interfaces protected by SAs: > >> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode > >> > >> the tunnel always adds encap. You can configure your SA to add additional > >> encap if you want. > > > >Ok, but that's not a replacement for the old functionality, right? The > > old functionality had the SA tunnel represented as an unnumbered interface > > that could be routed onto efficiently using the FIB. The unnumbered > > interface used the SA tunnel endpoint addresses. > > > > It is intended to be a replacement. If it's not then there's a problem and > > I'll address it. > > Great. :) > > > > > Both old an new have one critical thing in common, there's an interface and > > an inbound and outbound SA. > > The old functionality had a ip-in-ip interface tightly coupled to two SAs, > > so tight that there was a dedicated interface type, ipsecX, and the > > interface and SAs were configured at the same time. In the new model that > > coupling is loose; there's a ipip interface and its associated SAs, they > > are configured independently and bound together. > > If you made the ipsecX unnumbered you now make the ipipX unnumbered. If you > > had routes through ipsecX, now you route through IpipX. > > > >The wiki shows the that SA tunnel mode is re-encapsulating the already > > encapsulated IP-IP tunnel traffic. So now I have 3 IP headers instead of > > the 2 IP headers as before? > > > > If an SA is in transport mode it does not add headers, if it's in tunnel > > mode it does. When a packet egresses the tunnel it is encapped by that > > tunnel, if you don't want another set of IP headers then configure the SA > > that protects the tunnel to be in transport mode. > > So with the old functionality the interface was unnumbered, and used the SA > endpoint IPs for the it's encapsulating IP header. Using it with SA in tunnel > mode did not produce 3 IP headers. That's what we need to fix I guess, it > should only produce 2 IP headers, the user's and the SA tunnel IP header. > > You still have the choice to make the ipip interface unnumbered, or you can > assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was > and the new protected GRE interface can be) you can add it to a BD. The end > points of the tunnel are your choice. > > > > >Putting aside the wasted IP header bandwidth for the moment though, I > > don't understand what's actually supposed to be happening here. What does > > the configuration look like? I have an SA with endpoints > > (Local-IP,Remote-IP) and I have user traffic with (User-SIP,User-DIP). > > Previously I had an unnumbered interface that used the SAs > > (Local-IP,Remote-IP) for it's IP header. I then routed traffic for > > (User-DIP) over that unnumbered interface. How does one configure that with > > this ipip tunnel replacement? > > > > create ipip src Local-IP dst remote-IP > > set int unnum ipip0 use Eth0 > > ipsec sa add id 5 [crypto .. ] [integ ..] mode=transport > > ipsec sa add id 6 [crypto .. ] [integ ..] mode=transport > > ipsec tun protect ipip0 in 5 out 6 > > set int state ipip0 up > > > > ip route User-DIP/32 via ipip0 > > > > does that get you what you need? > > No, using transport mode IPsec is not an option. It must be an SA in standard > tunnel mode. And it can't have 3 IP headers. :) > > if your original packet that is routed into the tunnel was: > > [ IP (user-DIP, user-SIP) | TCP | Payload ] > > Then the above configuration will give you: > > [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | > Payload ] > > If you didn’t have protection on the tunnel interface, you’d get > > [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ] > > So the SA acts like transport mode, i.e. it’s inserting the ESP header > between the tunnel IP headers and the payload. This is what other uses are > using as a replacement for the old config. > If your SA was in tunnel mode, then you’d get: > > [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (SA-DIP, SA-SIP) | ESP | IP > (User-DIP, User-SIP) | TCP | Payload ] > > Which I think is the 3 headers you don’t want. > > Are there other properties of a tunnel mode SA that you need that are lost > with this approach? I need to use tunnel mode SAs provided by IKEv2. Transport mode is an optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These tunnel mode SAs will
Re: [vpp-dev] Assertion failure in nat_get_vlib_main() in snat_init()
Hi Elias,
Good to hear. Only ruined your morning then. ;-)
Best regards,
Ole
> On 8 May 2020, at 11:30, Elias Rudberg wrote:
>
> Hi Ole,
>
> Yes, that fixes it!
> With that patch my NAT test works, no more assertion failures.
>
> / Elias
>
>
> On Fri, 2020-05-08 at 10:06 +0200, Ole Troan wrote:
>> Hi Elias,
>>
>> Thanks for finding that one.
>> Can you verify that this patch fixes it:
>> https://gerrit.fd.io/r/c/vpp/+/26951 nat: fix per thread data
>> vlib_main_t usage take 2 [NEW]
>>
>> Best regards,
>> Ole
>>
>>> On 7 May 2020, at 22:57, Elias Rudberg
>>> wrote:
>>>
>>> Hello,
>>>
>>> With the current master branch (def78344) we now get an assertion
>>> failure on startup, here:
>>>
>>> (gdb) bt
>>> #0 __GI_raise (sig=sig@entry=6) at
>>> ../sysdeps/unix/sysv/linux/raise.c:51
>>> #1 0x7462e801 in __GI_abort () at abort.c:79
>>> #2 0x004071f3 in os_panic ()
>>> at vpp/src/vpp/vnet/main.c:366
>>> #3 0x7550d7d9 in debugger ()
>>> at vpp/src/vppinfra/error.c:84
>>> #4 0x7550d557 in _clib_error (how_to_die=2,
>>> function_name=0x0,
>>> line_number=0,
>>> fmt=0x7fffacbc0310 "%s:%d (%s) assertion `%s' fails")
>>> at vpp/src/vppinfra/error.c:143
>>> #5 0x7fffacac659e in nat_get_vlib_main (thread_index=4)
>>> at vpp/src/plugins/nat/nat.c:2557
>>> #6 0x7fffacabd7a5 in snat_init (vm=0x7639b980
>>> )
>>> at vpp/src/plugins/nat/nat.c:2685
>>> #7 0x760b9f66 in call_init_exit_functions_internal
>>> (vm=0x7639b980 ,
>>> headp=0x7639bfa8 , call_once=1,
>>> do_sort=1)
>>> at vpp/src/vlib/init.c:350
>>> #8 0x760b9e88 in vlib_call_init_exit_functions
>>> (vm=0x7639b980 ,
>>> headp=0x7639bfa8 , call_once=1)
>>> at vpp/src/vlib/init.c:364
>>> #9 0x760ba011 in vlib_call_all_init_functions
>>> (vm=0x7639b980 )
>>> at vpp/src/vlib/init.c:386
>>> #10 0x760df1f8 in vlib_main (vm=0x7639b980
>>> , input=0x7fffb4b2afa8)
>>> at vpp/src/vlib/main.c:2171
>>> #11 0x76166405 in thread0 (arg=140737324366208)
>>> at vpp/src/vlib/unix/main.c:658
>>> #12 0x75531954 in clib_calljmp ()
>>> at vpp/src/vppinfra/longjmp.S:123
>>> #13 0x7fffcf30 in ?? ()
>>> #14 0x76165f97 in vlib_unix_main (argc=57, argv=0x71d520)
>>> at vpp/src/vlib/unix/main.c:730
>>> #15 0x004068d8 in main (argc=57, argv=0x71d520)
>>> at vpp/src/vpp/vnet/main.c:291
>>>
>>> The code looks like this (this part was added in a recent commit it
>>> seems):
>>>
>>> always_inline vlib_main_t *
>>> nat_get_vlib_main (u32 thread_index)
>>> {
>>> vlib_main_t *vm;
>>> vm = vlib_mains[thread_index];
>>> ASSERT (vm);
>>> return vm;
>>> }
>>>
>>> So it is looking at vlib_mains[thread_index] but that is NULL,
>>> apparently.
>>>
>>> Since this happens at startup, could it be that vlib_mains has not
>>> been
>>> initialized yet, it is too early to try to access it?
>>>
>>> Is vlib_mains[thread_index] supposed to be initialized by the time
>>> when
>>> vlib_call_all_init_functions() runs?
>>>
>>> Best regards,
>>> Elias
>>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16282): https://lists.fd.io/g/vpp-dev/message/16282
Mute This Topic: https://lists.fd.io/mt/74060018/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] Assertion failure in nat_get_vlib_main() in snat_init()
Hi Ole,
Yes, that fixes it!
With that patch my NAT test works, no more assertion failures.
/ Elias
On Fri, 2020-05-08 at 10:06 +0200, Ole Troan wrote:
> Hi Elias,
>
> Thanks for finding that one.
> Can you verify that this patch fixes it:
> https://gerrit.fd.io/r/c/vpp/+/26951 nat: fix per thread data
> vlib_main_t usage take 2 [NEW]
>
> Best regards,
> Ole
>
> > On 7 May 2020, at 22:57, Elias Rudberg
> > wrote:
> >
> > Hello,
> >
> > With the current master branch (def78344) we now get an assertion
> > failure on startup, here:
> >
> > (gdb) bt
> > #0 __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> > #1 0x7462e801 in __GI_abort () at abort.c:79
> > #2 0x004071f3 in os_panic ()
> >at vpp/src/vpp/vnet/main.c:366
> > #3 0x7550d7d9 in debugger ()
> >at vpp/src/vppinfra/error.c:84
> > #4 0x7550d557 in _clib_error (how_to_die=2,
> > function_name=0x0,
> > line_number=0,
> >fmt=0x7fffacbc0310 "%s:%d (%s) assertion `%s' fails")
> >at vpp/src/vppinfra/error.c:143
> > #5 0x7fffacac659e in nat_get_vlib_main (thread_index=4)
> >at vpp/src/plugins/nat/nat.c:2557
> > #6 0x7fffacabd7a5 in snat_init (vm=0x7639b980
> > )
> >at vpp/src/plugins/nat/nat.c:2685
> > #7 0x760b9f66 in call_init_exit_functions_internal
> > (vm=0x7639b980 ,
> >headp=0x7639bfa8 , call_once=1,
> > do_sort=1)
> >at vpp/src/vlib/init.c:350
> > #8 0x760b9e88 in vlib_call_init_exit_functions
> > (vm=0x7639b980 ,
> >headp=0x7639bfa8 , call_once=1)
> >at vpp/src/vlib/init.c:364
> > #9 0x760ba011 in vlib_call_all_init_functions
> > (vm=0x7639b980 )
> >at vpp/src/vlib/init.c:386
> > #10 0x760df1f8 in vlib_main (vm=0x7639b980
> > , input=0x7fffb4b2afa8)
> >at vpp/src/vlib/main.c:2171
> > #11 0x76166405 in thread0 (arg=140737324366208)
> >at vpp/src/vlib/unix/main.c:658
> > #12 0x75531954 in clib_calljmp ()
> >at vpp/src/vppinfra/longjmp.S:123
> > #13 0x7fffcf30 in ?? ()
> > #14 0x76165f97 in vlib_unix_main (argc=57, argv=0x71d520)
> >at vpp/src/vlib/unix/main.c:730
> > #15 0x004068d8 in main (argc=57, argv=0x71d520)
> >at vpp/src/vpp/vnet/main.c:291
> >
> > The code looks like this (this part was added in a recent commit it
> > seems):
> >
> > always_inline vlib_main_t *
> > nat_get_vlib_main (u32 thread_index)
> > {
> > vlib_main_t *vm;
> > vm = vlib_mains[thread_index];
> > ASSERT (vm);
> > return vm;
> > }
> >
> > So it is looking at vlib_mains[thread_index] but that is NULL,
> > apparently.
> >
> > Since this happens at startup, could it be that vlib_mains has not
> > been
> > initialized yet, it is too early to try to access it?
> >
> > Is vlib_mains[thread_index] supposed to be initialized by the time
> > when
> > vlib_call_all_init_functions() runs?
> >
> > Best regards,
> > Elias
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16281): https://lists.fd.io/g/vpp-dev/message/16281
Mute This Topic: https://lists.fd.io/mt/74060018/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] Assertion failure in nat_get_vlib_main() in snat_init()
Hi Elias,
Thanks for finding that one.
Can you verify that this patch fixes it:
https://gerrit.fd.io/r/c/vpp/+/26951 nat: fix per thread data vlib_main_t usage
take 2 [NEW]
Best regards,
Ole
> On 7 May 2020, at 22:57, Elias Rudberg wrote:
>
> Hello,
>
> With the current master branch (def78344) we now get an assertion
> failure on startup, here:
>
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x7462e801 in __GI_abort () at abort.c:79
> #2 0x004071f3 in os_panic ()
>at vpp/src/vpp/vnet/main.c:366
> #3 0x7550d7d9 in debugger ()
>at vpp/src/vppinfra/error.c:84
> #4 0x7550d557 in _clib_error (how_to_die=2, function_name=0x0,
> line_number=0,
>fmt=0x7fffacbc0310 "%s:%d (%s) assertion `%s' fails")
>at vpp/src/vppinfra/error.c:143
> #5 0x7fffacac659e in nat_get_vlib_main (thread_index=4)
>at vpp/src/plugins/nat/nat.c:2557
> #6 0x7fffacabd7a5 in snat_init (vm=0x7639b980
> )
>at vpp/src/plugins/nat/nat.c:2685
> #7 0x760b9f66 in call_init_exit_functions_internal
> (vm=0x7639b980 ,
>headp=0x7639bfa8 , call_once=1,
> do_sort=1)
>at vpp/src/vlib/init.c:350
> #8 0x760b9e88 in vlib_call_init_exit_functions
> (vm=0x7639b980 ,
>headp=0x7639bfa8 , call_once=1)
>at vpp/src/vlib/init.c:364
> #9 0x760ba011 in vlib_call_all_init_functions
> (vm=0x7639b980 )
>at vpp/src/vlib/init.c:386
> #10 0x760df1f8 in vlib_main (vm=0x7639b980
> , input=0x7fffb4b2afa8)
>at vpp/src/vlib/main.c:2171
> #11 0x76166405 in thread0 (arg=140737324366208)
>at vpp/src/vlib/unix/main.c:658
> #12 0x75531954 in clib_calljmp ()
>at vpp/src/vppinfra/longjmp.S:123
> #13 0x7fffcf30 in ?? ()
> #14 0x76165f97 in vlib_unix_main (argc=57, argv=0x71d520)
>at vpp/src/vlib/unix/main.c:730
> #15 0x004068d8 in main (argc=57, argv=0x71d520)
>at vpp/src/vpp/vnet/main.c:291
>
> The code looks like this (this part was added in a recent commit it
> seems):
>
> always_inline vlib_main_t *
> nat_get_vlib_main (u32 thread_index)
> {
> vlib_main_t *vm;
> vm = vlib_mains[thread_index];
> ASSERT (vm);
> return vm;
> }
>
> So it is looking at vlib_mains[thread_index] but that is NULL,
> apparently.
>
> Since this happens at startup, could it be that vlib_mains has not been
> initialized yet, it is too early to try to access it?
>
> Is vlib_mains[thread_index] supposed to be initialized by the time when
> vlib_call_all_init_functions() runs?
>
> Best regards,
> Elias
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16280): https://lists.fd.io/g/vpp-dev/message/16280
Mute This Topic: https://lists.fd.io/mt/74060018/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 tunnel interfaces?
From: on behalf of Christian Hopps Date: Thursday 7 May 2020 at 23:27 To: "Neale Ranns (nranns)" Cc: Christian Hopps , vpp-dev Subject: Re: [vpp-dev] IPsec tunnel interfaces? > On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > On 07/05/2020 16:55, "Christian Hopps" wrote: > > > >> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote: >> >> >> Hi Chris, >> >> They were replaced by ipip interfaces protected by SAs: >> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode >> >> the tunnel always adds encap. You can configure your SA to add additional >> encap if you want. > >Ok, but that's not a replacement for the old functionality, right? The old > functionality had the SA tunnel represented as an unnumbered interface that > could be routed onto efficiently using the FIB. The unnumbered interface used > the SA tunnel endpoint addresses. > > It is intended to be a replacement. If it's not then there's a problem and > I'll address it. Great. :) > > Both old an new have one critical thing in common, there's an interface and > an inbound and outbound SA. > The old functionality had a ip-in-ip interface tightly coupled to two SAs, so > tight that there was a dedicated interface type, ipsecX, and the interface > and SAs were configured at the same time. In the new model that coupling is > loose; there's a ipip interface and its associated SAs, they are configured > independently and bound together. > If you made the ipsecX unnumbered you now make the ipipX unnumbered. If you > had routes through ipsecX, now you route through IpipX. > >The wiki shows the that SA tunnel mode is re-encapsulating the already > encapsulated IP-IP tunnel traffic. So now I have 3 IP headers instead of the > 2 IP headers as before? > > If an SA is in transport mode it does not add headers, if it's in tunnel mode > it does. When a packet egresses the tunnel it is encapped by that tunnel, if > you don't want another set of IP headers then configure the SA that protects > the tunnel to be in transport mode. So with the old functionality the interface was unnumbered, and used the SA endpoint IPs for the it's encapsulating IP header. Using it with SA in tunnel mode did not produce 3 IP headers. That's what we need to fix I guess, it should only produce 2 IP headers, the user's and the SA tunnel IP header. You still have the choice to make the ipip interface unnumbered, or you can assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was and the new protected GRE interface can be) you can add it to a BD. The end points of the tunnel are your choice. >Putting aside the wasted IP header bandwidth for the moment though, I > don't understand what's actually supposed to be happening here. What does the > configuration look like? I have an SA with endpoints (Local-IP,Remote-IP) and > I have user traffic with (User-SIP,User-DIP). Previously I had an unnumbered > interface that used the SAs (Local-IP,Remote-IP) for it's IP header. I then > routed traffic for (User-DIP) over that unnumbered interface. How does one > configure that with this ipip tunnel replacement? > > create ipip src Local-IP dst remote-IP > set int unnum ipip0 use Eth0 > ipsec sa add id 5 [crypto .. ] [integ ..] mode=transport > ipsec sa add id 6 [crypto .. ] [integ ..] mode=transport > ipsec tun protect ipip0 in 5 out 6 > set int state ipip0 up > > ip route User-DIP/32 via ipip0 > > does that get you what you need? No, using transport mode IPsec is not an option. It must be an SA in standard tunnel mode. And it can't have 3 IP headers. :) if your original packet that is routed into the tunnel was: [ IP (user-DIP, user-SIP) | TCP | Payload ] Then the above configuration will give you: [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | Payload ] If you didn’t have protection on the tunnel interface, you’d get [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ] So the SA acts like transport mode, i.e. it’s inserting the ESP header between the tunnel IP headers and the payload. This is what other uses are using as a replacement for the old config. If your SA was in tunnel mode, then you’d get: [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (SA-DIP, SA-SIP) | ESP | IP (User-DIP, User-SIP) | TCP | Payload ] Which I think is the 3 headers you don’t want. Are there other properties of a tunnel mode SA that you need that are lost with this approach? /neale Thanks, Chris. > >I did read through the Wiki and it seems that this change was motivated by > wanting to cleanup the IPsec API, but that hardly seems like justification to > eliminate the efficient use of an entire variant of commonly used IPsec > functionality. > > Cleaning up the API was one motivation. It was a pain that each time we added > new attributes to SA creation (like ESN, UDP, algo=foo) (for use with the > SPD) we had to make similar changes to both the ipsec and
