Damjan,
On 1/30/19 3:29 PM, Damjan Marion via Lists.Fd.Io wrote:
>
> Folks,
>
> Anybody can help with understanding why opensuse jobs are failing with:
>
> *13:54:57*
> /w/workspace/vpp-verify-master-osleap15/build-root/rpmbuild/BUILD/vpp-19.04/src/plugins/nsim/nsim.c:620:1:
> fatal error: er
What about /var/log/syslog? Do you have any lisp specific errors there?
Seems that you have v6 traffic going for vni 10. Did you statically configure
the mapping for fd00:74::/48? If not, then map-replies with vni non 0 seem to
be working.
What map-reply isn’t correctly parsed? Is it for th
Look the show error
vpp# show error
CountNode Reason
334 dpdk-input no error
166 lisp-cp-input drop
165 lisp-cp-input map-notifies received
14
I am testing shared mode, is make by:
- 1Map server with 2 instance iid(20 ipv6 and 30 ipv4), same key . Cisco router.
-3 VPP on ubuntu. Each VPP has 2 table-id(20and30) linked to differents
interfaces and of course map (vni to iid). The RLOC is located on table-id 0.
On Cisco router whith s
All,
the jenkins jobs were extremely slow today, and the final verify merge
job in a remerge after the tag push appears to be stuck. It's 2am so
I will take a break and see if it might recover in the morning. I
opened a ticket about this.
The packagecloud and all but one nexus repositories have
Are you testing a shared-mode or parallel-mode topology?
On Wed, Jan 30, 2019 at 7:11 PM Florin Coras wrote:
> As per previous email, please check for any errors reported by lisp-cp in
> cli and syslog.
>
> Florin
>
> On Jan 30, 2019, at 9:50 AM, Yosvany wrote:
>
> Yes was solved, but we have m
As per previous email, please check for any errors reported by lisp-cp in cli
and syslog.
Florin
> On Jan 30, 2019, at 9:50 AM, Yosvany wrote:
>
> Yes was solved, but we have map-reply problem, it is drop by lisp-cp when vni
> is differents that 0.
>
>
>
> El 29 de enero de 2019 8:37:45
Yes was solved, but we have map-reply problem, it is drop by lisp-cp when vni
is differents that 0.
El 29 de enero de 2019 8:37:45 PM GMT-05:00, Florin Coras
escribió:
>Does this [1] solve the issue?
>
>Florin
>
>[1] https://gerrit.fd.io/r/#/c/17151/
>
>> On Jan 29, 2019, at 4:34 PM, Yosvany
Hi Paul,
We don’t have lisp control message tracing. But it may very well be that the
new pcap tracer is enough.
Florin
> On Jan 30, 2019, at 11:49 AM, Paul Vinciguerra
> wrote:
>
> Hi Florin,
>
> Is lisp control message tracing needed, or is it better to use the new
> wireshark extension
Today is the fd.io vpp project 19.01 final release date. This is a really bad
time for infrastructure issues. Please plan on turning up at tomorrow's TSC
meeting with a detailed explanation of what went wrong.
D.
-Original Message-
From: t...@lists.fd.io On Behalf Of Vanessa Valderram
Hi folks,
Give the following patch a try and let me know.
https://gerrit.fd.io/r/#/c/17184/
I have done some very basic testing with SW cryptodev with single queue pair
and all seems fine.
Let me know if there is any issue with it.
Regards,
Sergio
From: Roberts
Jenkins restart is complete. Please open an RT ticket if you experience
any additional issues.
Thank you,
Vanessa
On 01/30/2019 01:34 PM, Vanessa Valderrama wrote:
> We have placed Jenkins into shutdown mode. It will require a restart to
> resolve slowness. We'll do the restart at the top of t
Hi Florin,
Is lisp control message tracing needed, or is it better to use the new
wireshark extensions?
On Wed, Jan 30, 2019 at 1:23 PM Florin Coras wrote:
> Yosvany,
>
> The trace you provided shows that the packet was processed okay and then
> dropped. Do you see any lisp errors if you do “sh
I would like the https://gerrit.fd.io/r/#/c/17173/ to finish before
the restart, it is almost there...
--a
On 1/30/19, Vanessa Valderrama wrote:
> We have placed Jenkins into shutdown mode. It will require a restart to
> resolve slowness. We'll do the restart at the top of the hour. Please
> le
We have placed Jenkins into shutdown mode. It will require a restart to
resolve slowness. We'll do the restart at the top of the hour. Please
let us know as soon as possible if there are any builds that cannot be
terminated if not complete. We apologize for the inconvenience and hope
to have this
Yosvany,
The trace you provided shows that the packet was processed okay and then
dropped. Do you see any lisp errors if you do “show error” or in syslog?
It may turn out to be that we don’t have a parser for some record in the
map-reply. Note that testing has been done exclusively with ODL Li
TO ALL COMMITTERS:
I am in the process of cutting the 19.01 release.
Please, do NOT merge any patches onto stable/1901 until the release has been
announced on vpp-dev@lists.fd.io
--a
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12071): https://
VPP are delete LISP map reply from cisco router as LISP MR/MS when VPP are
making Map-Request to good EID.
The problem is when vni map to iid is differents that 0.
When response map-reply is native forward, VPP work fine.
When response is good VPP dont show the result on one eid-table remote.
Dear All,
We propose to deprecate the STN plugin in favour of the ipX_redirect punt
feature.
For all those with objections please raise them AYEC.
Thanks,
Neale
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12069): https://lists.fd.io/g/vpp-
Hi Raj,
> On Jan 30, 2019, at 6:49 AM, Raj wrote:
>
> Hello Florin,
>
> Thanks a lot for your reply.
>
> On Tue, Jan 29, 2019 at 9:15 PM Florin Coras wrote:
>>
>> VPP typically works best if configured with a relatively small number of
>> buffers.
>
> I am trying to understand why this wo
> On 30 Jan 2019, at 16:26, Paul Vinciguerra wrote:
>
> I would agree that the error seems to indicate that the build-host has
> insufficient /tmp space.
>
> There is no doubt, that the build system, like the test system, could use
> some love.
> What is your feeling on moving the CI logic
I would agree that the error seems to indicate that the build-host has
insufficient /tmp space.
There is no doubt, that the build system, like the test system, could use
some love.
What is your feeling on moving the CI logic out of the makefile?
Do you care about the error, or do you care about
Hello Florin,
Thanks a lot for your reply.
On Tue, Jan 29, 2019 at 9:15 PM Florin Coras wrote:
>
> VPP typically works best if configured with a relatively small number of
> buffers.
I am trying to understand why this would be the case.
> On the other hand, nsim can induce a large amount of d
Hello Klement,
Ti works with your patch set 2:
Tests.Vpp.Perf.Crypto
==
Tests.Vpp.Perf.Crypto.40Ge2P1Xl710-Ethip4Ipsecbasetnl-Ip4Base-Int-Aes-Gcm-M...
=
> Anybody can help with understanding why opensuse jobs are failing with:
> 13:54:57 /w/workspace/vpp-verify-master-osleap15/build-
> root/rpmbuild/BUILD/vpp-19.04/src/plugins/nsim/nsim.c:620:1: fatal error:
> error writing to /tmp/ccJaw6Cw.s: Cannot allocate memory
Could it be that /tmp is mounte
Folks,
Anybody can help with understanding why opensuse jobs are failing with:
13:54:57
/w/workspace/vpp-verify-master-osleap15/build-root/rpmbuild/BUILD/vpp-19.04/src/plugins/nsim/nsim.c:620:1:
fatal error: error writing to /tmp/ccJaw6Cw.s: Cannot allocate memory
13:54:57 };
13:54:57 ^
13:5
Hi All,
As you know a while back we introduced the use of typesdef and enums for use in
VPP’s .api files.
Example types are mac_address_t, address_t and prefix_t.
This patch:
https://gerrit.fd.io/r/#/c/14138/
updates all the APIs in ip.api to use these new types and new enums where
appropri
Hello everyone,
I've just come back from vacation and picked this up again.
I've not yet found a pretty solution to the issues that are present when using
NAT on a large scale and communicating with sources that require clients to
communicate from the same external IP. I had hoped we wouldn't n
Can you please try this patch and let me know if it fixes things for you?
https://gerrit.fd.io/r/17163
Thanks,
Klement
Quoting Klement Sekera via Lists.Fd.Io (2019-01-30 11:08:12)
> Hi,
>
> I see the issue, will come up with a patch shortly.
>
> Thanks,
> Klement
>
> Quoting Jan Gelety via Li
Hi,
I see the issue, will come up with a patch shortly.
Thanks,
Klement
Quoting Jan Gelety via Lists.Fd.Io (2019-01-30 10:22:18)
>Hello vpp-dev team,
>
>
>
>Our csit performance tests for Ipsec using aes-gcm ciphering started to
>fail because created ipsec interface cannot get
Hello vpp-dev team,
Our csit performance tests for Ipsec using aes-gcm ciphering started to fail
because created ipsec interface cannot get to up state - tested with vpp master
(build 19.04-rc0~67-g72de626~b6198) as well as with stable/1901 (build
19.01-rc2~3-g9124874~b2).
We are using HW cryp
VPP deals with tables not VRFs. A VRF is a single identifier for a set of 4
tables; IPv4 & IPv6, unicast and multicast. In VPP we have instead one ID to
describe the pair of IPv4 unicast plus multicast and another ID (in a separate
number space) to describe the same IPv6 pair. A VRF is then onl
32 matches
Mail list logo
