Dear Miguel,
Here's another trick: "pcap drop trace on max 100 intfc " -
send pkts - "pcap drop trace off".
This will create a pcap trace of packets received on which were
dropped, in /tmp/drop.pcap.
It sure looks like this will capture the nsh packets inquestion, so you can
check them in Wi
Hi Miguel,
Yes, you are right. C1,C2,C3 and C4 are not part of NSH key.
Could you capture the packet sent from CLASSIFIER1?
Or using packet trace in VPP to see what the real packet contains?
That would be helpful.
Thanks,
Hongjun
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.f
Thanks Dave, this really helped me (I used the pcap tx trace before but your
suggestion offers much more information).
Below is the info I got. It shows that the nsh-input gets wrong values and it
matches what I see with wireshark. However the ovs-dpctl dump-flows in
CLASSIFIER1 shows completely
Please see if vpp packet tracer will show you why the packets aren't behaving
as required...
For example:
Vpp# trace add dpdk-input 50
Vpp# show trace
HTH... Thanks... Dave
P.S. you might need to specify a node other than dpdk-input if e.g. you're
using tap, af_packet, etc. other sorts of in
>>Only slightly :-)
Thank you, Christian. The one thing I don't know is whether there is
anybody on the list who feels that they need the module with the
CONFIG_VFIO_NOIOMMU set. Actually, I have a huge hole in my knowledge base
in the entire area of VFIO, UIO, IOMMU. But if there is interest in a
Hi Andrew,
You observation is right. I was running vpp_lite with a buffer size of 512.
As you mentioned, defining PING_MAXIMUM_DATA_SIZE conditionally should work.
I have opened a jira ticket for this: https://jira.fd.io/browse/VPP-621
Thanks,
-nagp
On Fri, Jan 27, 2017 at 7:23 PM, Andrew 👽 You
FYI, I've backed out the change to build.sh to run "make test" instead
of building the packages because vpp-csit-verify-master-virl uses this
behavior to build the correct packages.
Thanks,
-daw-
On 01/26/2017 10:04 PM, Dave Wallace wrote:
Keith,
Please test the following patch for compatibi
Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with
this setup:
+-+
| Host (ODL SFC) |
| 192.168.60.1 |
+-+
Hi Gabriel,
Thanks. I have pulled lates from master and i can see your commit.
I will try it as soon as possible.
Regards,
Yusuf
On Fri, Jan 27, 2017 at 9:32 PM, Gabriel Ganne
wrote:
> Hi Yusuf,
>
>
> I wrote a small patch which is supposed to take care of this issue :
> https://gerrit.fd.io/r
Hi Yusuf,
I wrote a small patch which is supposed to take care of this issue :
https://gerrit.fd.io/r/#/c/4894/
I believe it was merged this morning.
If you're not upstream, please pull and try again.
Otherwise tell me so I'll look into what can cause this.
Best regards,
Gerrit Code Revi
Hi Team,
I am able to build vpp on centos vm but it failes while creating the rpm
package. with below error. All the dependencies are installed.
---
Processing files: vpp-debuginfo-17.04-rc0~141_g1730077.x86_64
Provides: vpp-debu
That patch was the result of a less-than-optimal cleanup effort on my part.
Until I did that, the plugins had their own copies of the M, M2, S, and W
macros, each of which had some version of (VL_API_MUMBLE + plugin_msg_base).
I fucked up all of them in one motion when I got rid of N-1 cut-‘n-pa
On Thu, Jan 26, 2017 at 4:38 PM, Jon Loeliger wrote:
>
>
> Does this same mechanism hold true for the VPE messages? Is the collection
> of the VPE message considered "a plugin", or "a base onto which plugins
> will
> be added"? There are currently 20 or 21 include files' worth of msg ids
> here.
Hello,
> On 27 Jan 2017, at 04:12, Nagaprabhanjan Bellaru wrote:
>
> Hi,
>
> I am not sure if the ping debug CLI is being actively used, but the function
> "init_icmp46_echo_request" goes ahead and writes 2000 bytes into the
> vlib_buffer corrupting the surrounding memory area. After 3-4 ping
Thanks Dave!
/neale
On 27/01/2017, 02:16, "Dave Wallace" wrote:
Klement/Neale,
I finally got back to debugging this issue. After doing a make
test-wipe, then make test. The patched python files and their
corresponding .pyc files had the same timestamp with a 1-second
Hi Dave,
my research says that the timestamp is inside the .pyc file and that the
modification time of the file is ignored. I tried to fool python by
having a source compiled, the changing the source file and touching the
.pyc file to see if it'll use stale bytecode, but it didn't.
Either way - i
On Thu, Jan 26, 2017 at 6:46 PM, Burt Silverman wrote:
> Thanks, Christian, this is great information.
>
> Just for fun, before I read this, I wanted to test some of my kernel
> building skills. So I just wish to build modules in the drivers/vfio
> directory. I want to do what might be called "bu
17 matches
Mail list logo
