Re: [vpp-dev] event-logger output format

[Balaji Venkatraman via Lists.Fd.Io]

Do you think it would be prudent to publish a ‘warning’ message on its impact 
on packet forwarding when this cmd is used?

Thanks!

--
Regards,
Balaji.


From:  on behalf of Aleksander Djuric 

Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] event-logger output format

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146


On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.



Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...



I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.



FWIW... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14425): https://lists.fd.io/g/vpp-dev/message/14425
Mute This Topic: https://lists.fd.io/mt/40103349/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] event-logger output format

[Balaji Venkatraman via Lists.Fd.Io]

Dave,
Couldn’t have explained it better! Thanks much!

Given that most CPU’s are 2+ cores, it should be okay but, you say “Note that 
most debug CLI commands are not marked thread-safe”

Does it mean, it might they would still revert to a single-core like operation?

Thanks!
--
Regards,
Balaji.


From: "Dave Barach (dbarach)" 
Date: Thursday, October 31, 2019 at 12:27 PM
To: "Balaji Venkatraman (balajiv)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] event-logger output format

Two cases: in single-core operation, debug CLI commands change the NDR / max 
throughput. A single “format” call might cost as many clock cycles as 
processing 50 packets. If the one and only core is busy printing something, 
it’s not processing packets.

In multi-core operation, CLI commands typically don’t change the NDR / max 
throughput numbers so long as they are marked thread_safe. Examples include 
“show run.” Note that most debug CLI commands are not marked thread-safe.

I think that folks will complain early and often if we start printing 
disclaimers every time vpp executes a non-thread-safe debug CLI command.

It wouldn’t be hard to count and [eventually] report non-thread-safe debug CLI 
commands. All such barrier sync calls originate in one place, in src/vlib/cli.c:

if (!c->is_mp_safe)
   vlib_worker_thread_barrier_sync (vm);

c_error = c->function (vm, si, c);

if (!c->is_mp_safe)
   vlib_worker_thread_barrier_release (vm);

What do people think?

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Balaji Venkatraman 
via Lists.Fd.Io
Sent: Thursday, October 31, 2019 12:21 PM
To: Aleksander Djuric ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format

Do you think it would be prudent to publish a ‘warning’ message on its impact 
on packet forwarding when this cmd is used?

Thanks!

--
Regards,
Balaji.


From: mailto:vpp-dev@lists.fd.io>> on behalf of Aleksander 
Djuric mailto:aleksander.dju...@gmail.com>>
Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] event-logger output format

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146


On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.



Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...



I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.



FWIW... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14442): https://lists.fd.io/g/vpp-dev/message/14442
Mute This Topic: https://lists.fd.io/mt/40103349/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [SUSPECTED SPAM] Re: [vpp-dev] How to add plugin in running VPP ?

[Balaji Venkatraman via Lists.Fd.Io]

Instead of being excessively invasive to achieve HA, as Ole suggests, might be 
easier to spin off another instance based on some critical parameters. A 
kubernetes-like external agent that can be user configured to save the last 
config and reload the instances with the new plugin, or even restart the 
instances based on rules or policies.

Thanks!

--
Regards,
Balaji.


From:  on behalf of Ole Troan 
Date: Friday, December 13, 2019 at 9:42 AM
To: "Dave Barach (dbarach)" 
Cc: "chu.penghong" , "vpp-dev@lists.fd.io" 

Subject: [SUSPECTED SPAM] Re: [vpp-dev] How to add plugin in running VPP ?

> As of today, plugins are loaded early enough in the vpp init sequence; 
> everything which can be done in core engine code can also be done from 
> plugins. They are not removed and they are not updated after vpp starts.
>
> Making plugins removable or updateable would take considerable attention to 
> detail, and doesn’t seem worth the amount of work involved, especially with 
> respect to plugin API changes.
>
> Plugins would need “unload_prep” methods, with fine-grained controls to 
> minimize unnecessary data-structure teardowns. Best to keep FIBs and session 
> tables and so on intact if data structures match.
>
> In my own production use of vpp, I expect a single vpp process to run for up 
> to a year. Updates are scheduled in advance. The vpp update portion of the 
> exercise typically takes about 10 seconds.
>
> I’d be interested in hearing from the community: should we think about how to 
> refactor the entire code base to support arbitrary plugin load / unload / 
> reload scenarios? I don’t think it’s worth the amount of effort involved, but 
> that just my view.

Isn't this a pets vs cattle culture crash?
On one side of the spectrum you have the always up HA systems with Non-stop 
forwarding and ISSU etc, and on the other side the "just spin up a new thing 
(bare metal/container/VM/process) if anything needs changing".

I would be very cautious of the "old way" of achieving robustness. The added 
complexity is going to make the system harder to develop in, slow down feature 
velocity, and likely decrease robustness instead of improving on it.

Best regards,
Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14887): https://lists.fd.io/g/vpp-dev/message/14887
Mute This Topic: https://lists.fd.io/mt/68267897/1978096
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [bala...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14888): https://lists.fd.io/g/vpp-dev/message/14888
Mute This Topic: https://lists.fd.io/mt/68530953/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] make test - Python3 update

[Balaji Venkatraman via Lists.Fd.Io]

Hi Ole,
Appreciate all the efforts!
Any reason why we shouldn’t make PYTHON=python3.6 the default option?
That way, we would enforce development here on is 3.6 compliant.
Thanks much!
—
Regards,
Balaji.

On Oct 22, 2019, at 1:56 AM, Ole Troan  wrote:


All,

You might have seen the raft of python3 test commits going in over the last few 
days.
The last one went in this morning, and we now have a clean run on both Python 
2.7 and Python 3.6.

Andrew has added a verify job here:
http://s5ci.myvpp.net/jobs/test-vpp-make-test-python3/

The intention is also to have a voting verify job in jenkins.
And then decide on a community call of how long a overlapping period we should 
have (supporting both Python 2.7 and Python 3).

In the meantime, it would be appreciated if you didn't break Python 3 support 
too much.
To run with Python 3:
PYTHON=python3.6;make test TEST_JOBS=auto

Best regards,
Ole


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14260): https://lists.fd.io/g/vpp-dev/message/14260
Mute This Topic: https://lists.fd.io/mt/36392769/1978096
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [bala...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14263): https://lists.fd.io/g/vpp-dev/message/14263
Mute This Topic: https://lists.fd.io/mt/36392769/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] Basic l2 bridging does not work

[Balaji Venkatraman via Lists.Fd.Io]

+-+
| |
| |
|   IXIA  |
| |
| |
+---^-+
|172.16.1.1/24  | 172.16.1.2/24
|   |
|   |
|eth0   | eth0
+---v-+++---+
|   1 ||4   |
| |||
| |||
| |||
| |eth1  eth1  ||
|VPP1   2 +> 3VPP 2 |
| |||
| |||
| |||
| |||
+-+++
 R 740   R 230


Might help if you could check if the packet counts at ingress (port 1) & egress 
(port 2) match. Similarly 3 & 4. And the mac entries seen on both vpp(s). ARP 
req/rep tracing might also help.


/-
Balaji




From:  on behalf of "Damjan Marion via Lists.Fd.Io" 

Reply-To: "dmar...@me.com" 
Date: Wednesday, October 16, 2019 at 5:12 PM
To: "chuan...@google.com" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Basic l2 bridging does not work


On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io 
mailto:chuanhan=google@lists.fd.io>> wrote:

Hi, vpp experts,

We are trying to make basic l2 bridge works within vpp.

We have two servers: r230 and r740, each of which has two phy nics. Two servers 
are connected via cable. On each server, we bring these two nics into the same 
vpp instance and put them into the same l2 bridge. We tried sending traffic 
using ixia. However, ixia shows ping does not work.

I attached the topology, vpp conf files, startup conf file, and logs.

Please advise where we could make it wrong.

Thanks.
Chuan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189
Mute This Topic: https://lists.fd.io/mt/34655826/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

On the 1st look everything look ok including the packet trace.
Can you try to clear counters* and enable packet trace on both instances.
Then send known number of packets and find put where drop happens by looking 
into same outputs you already shared.

* "clear int", "clear run", "clear trace"

--
Damjan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14191): https://lists.fd.io/g/vpp-dev/message/14191
Mute This Topic: https://lists.fd.io/mt/34655826/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] VPP IPSec failed to add SA

[Balaji Venkatraman via Lists.Fd.Io]

I think the vpp-plugin-core, vpp-plugin-dpdk should carry them:

sudo apt-get install vpp-plugin-core vpp-plugin-dpdk

and confirm the crypto engine is loaded :

show plugins


--
Regards,
Balaji.


From: "Ying, Ruoyu" 
Date: Friday, October 18, 2019 at 8:43 AM
To: "Neale Ranns (nranns)" , "Filip Tehlar -X (ftehlar - 
PANTHEON TECHNOLOGIES at Cisco)" , "Balaji Venkatraman 
(balajiv)" , "vpp-dev@lists.fd.io" 
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Neale,

I’m really new to VPP and can you tell me where’s the plugins you mentioned? 
Thanks a lot.


Best Regards,
Ruoyu

From: vpp-dev@lists.fd.io  On Behalf Of Neale Ranns via 
Lists.Fd.Io
Sent: Friday, October 18, 2019 4:02 PM
To: Ying, Ruoyu ; Filip Tehlar -X (ftehlar - PANTHEON 
TECHNOLOGIES at Cisco) ; Balaji Venkatraman (balajiv) 
; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi Ruoyo,

You need to load one of the crypto_* plugins that provide the engine functions.

/neale


From: "Ying, Ruoyu" mailto:ruoyu.y...@intel.com>>
Date: Friday 18 October 2019 at 09:44
To: "Filip Tehlar -X (ftehlar - PANTHEON TECHNOLOGIES at Cisco)" 
mailto:fteh...@cisco.com>>, "Balaji Venkatraman (balajiv)" 
mailto:bala...@cisco.com>>, "Neale Ranns (nranns)" 
mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Filip,

I tried them also, but I still get a similar error:
vpp# set crypto handler aes-128-cbc openssl
failed to set engine openssl for aes-128-cbc!
vpp# set crypto handler aes-128-cbc ia32
failed to set engine ia32 for aes-128-cbc!

And the handlers look like this:
vpp# sh crypto handlers
AlgoTypeActive  Candidates
(nil)
des-cbc encrypt
decrypt
3des-cbcencrypt
decrypt
aes-128-cbc encrypt
decrypt
aes-192-cbc encrypt
decrypt
aes-256-cbc encrypt
decrypt
aes-128-ctr encrypt
decrypt
aes-192-ctr encrypt
decrypt
aes-256-ctr encrypt
decrypt
aes-128-gcm aead-encrypt
aead-decrypt
aes-192-gcm aead-encrypt
aead-decrypt
aes-256-gcm aead-encrypt
aead-decrypt
hmac-md5hmac
hmac-sha-1  hmac
hmac-sha-224hmac
hmac-sha-256hmac
hmac-sha-384hmac
hmac-sha-512hmac

Am I setting with the correct command? Thanks a lot.


Best Regards,
Ruoyu



From: Filip Tehlar -X (ftehlar - PANTHEON TECHNOLOGIES at Cisco) 
mailto:fteh...@cisco.com>>
Sent: Friday, October 18, 2019 3:29 PM
To: Ying, Ruoyu mailto:ruoyu.y...@intel.com>>; Balaji 
Venkatraman (balajiv) mailto:bala...@cisco.com>>; Neale 
Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Ruoyu,

Just replace „engine“ with an actual engine name, example:

DBGvpp# show crypto engines
NamePrioDescription
ia32100 Intel IA32 ISA Optimized Crypto
ipsecmb 80  Intel(R) Multi-Buffer Crypto for IPsec Library 
0.52.0
openssl 50  OpenSSL

DBGvpp# set crypto handler aes-128-cbc ia32
DBGvpp#

Filip
[cid:image001.png@01D5860D.6ADCA6C0]
Filip Tehlar
Engineer - Software
fteh...@cisco.com
Tel: +421 2 5825 5068




Cisco Systems, Inc.
Pribinova Street 10 Central 3
BRATISLAVA
81109
Slovakia
cisco.com
[cid:image002.gif@01D5860D.6ADCA6C0]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Ying, Ruoyu
Sent: Friday, October 18, 2019 4:29 AM
To: Balaji Venkatraman (balajiv) mailto:bala...@cisco.com>>; 
Neale Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi Balaji,

I checked the docs and tried to set the handler engine. Since there’s no 
example for the command, I’m not sure if I’m setting the right value for 
‘cipher’ here. I tried with different values, but it just returns error msg 
like this:
vpp# set crypto handler aes-128-cbc engine
failed to set engine engine for aes-128-cbc!

vpp# set crypto handler openssl engine
failed 

Re: [vpp-dev] VPP IPSec failed to add SA

[Balaji Venkatraman via Lists.Fd.Io]

Perhaps this doc might be useful..

https://docs.fd.io/vpp/19.04/dpdk_crypto_ipsec_doc.html


--
Regards,
Balaji.


From: "Balaji Venkatraman (balajiv)" 
Date: Friday, October 18, 2019 at 8:58 AM
To: "Ying, Ruoyu" , "Neale Ranns (nranns)" 
, "Filip Tehlar -X (ftehlar - PANTHEON TECHNOLOGIES at 
Cisco)" , "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

I think the vpp-plugin-core, vpp-plugin-dpdk should carry them:

sudo apt-get install vpp-plugin-core vpp-plugin-dpdk

and confirm the crypto engine is loaded :

show plugins


--
Regards,
Balaji.


From: "Ying, Ruoyu" 
Date: Friday, October 18, 2019 at 8:43 AM
To: "Neale Ranns (nranns)" , "Filip Tehlar -X (ftehlar - 
PANTHEON TECHNOLOGIES at Cisco)" , "Balaji Venkatraman 
(balajiv)" , "vpp-dev@lists.fd.io" 
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Neale,

I’m really new to VPP and can you tell me where’s the plugins you mentioned? 
Thanks a lot.


Best Regards,
Ruoyu

From: vpp-dev@lists.fd.io  On Behalf Of Neale Ranns via 
Lists.Fd.Io
Sent: Friday, October 18, 2019 4:02 PM
To: Ying, Ruoyu ; Filip Tehlar -X (ftehlar - PANTHEON 
TECHNOLOGIES at Cisco) ; Balaji Venkatraman (balajiv) 
; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi Ruoyo,

You need to load one of the crypto_* plugins that provide the engine functions.

/neale


From: "Ying, Ruoyu" mailto:ruoyu.y...@intel.com>>
Date: Friday 18 October 2019 at 09:44
To: "Filip Tehlar -X (ftehlar - PANTHEON TECHNOLOGIES at Cisco)" 
mailto:fteh...@cisco.com>>, "Balaji Venkatraman (balajiv)" 
mailto:bala...@cisco.com>>, "Neale Ranns (nranns)" 
mailto:nra...@cisco.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Filip,

I tried them also, but I still get a similar error:
vpp# set crypto handler aes-128-cbc openssl
failed to set engine openssl for aes-128-cbc!
vpp# set crypto handler aes-128-cbc ia32
failed to set engine ia32 for aes-128-cbc!

And the handlers look like this:
vpp# sh crypto handlers
AlgoTypeActive  Candidates
(nil)
des-cbc encrypt
decrypt
3des-cbcencrypt
decrypt
aes-128-cbc encrypt
decrypt
aes-192-cbc encrypt
decrypt
aes-256-cbc encrypt
decrypt
aes-128-ctr encrypt
decrypt
aes-192-ctr encrypt
decrypt
aes-256-ctr encrypt
decrypt
aes-128-gcm aead-encrypt
aead-decrypt
aes-192-gcm aead-encrypt
aead-decrypt
aes-256-gcm aead-encrypt
aead-decrypt
hmac-md5hmac
hmac-sha-1  hmac
hmac-sha-224hmac
hmac-sha-256hmac
hmac-sha-384hmac
hmac-sha-512hmac

Am I setting with the correct command? Thanks a lot.


Best Regards,
Ruoyu



From: Filip Tehlar -X (ftehlar - PANTHEON TECHNOLOGIES at Cisco) 
mailto:fteh...@cisco.com>>
Sent: Friday, October 18, 2019 3:29 PM
To: Ying, Ruoyu mailto:ruoyu.y...@intel.com>>; Balaji 
Venkatraman (balajiv) mailto:bala...@cisco.com>>; Neale 
Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] VPP IPSec failed to add SA

Hi Ruoyu,

Just replace „engine“ with an actual engine name, example:

DBGvpp# show crypto engines
NamePrioDescription
ia32100 Intel IA32 ISA Optimized Crypto
ipsecmb 80  Intel(R) Multi-Buffer Crypto for IPsec Library 
0.52.0
openssl 50  OpenSSL

DBGvpp# set crypto handler aes-128-cbc ia32
DBGvpp#

Filip
[cid:image001.png@01D5860D.6ADCA6C0]
Filip Tehlar
Engineer - Software
fteh...@cisco.com
Tel: +421 2 5825 5068




Cisco Systems, Inc.
Pribinova Street 10 Central 3
BRATISLAVA
81109
Slovakia
cisco.com
[cid:image002.gif@01D5860D.6ADCA6C0]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Ying, Ruoyu
Sent: Friday, October 18, 2019 4:29 AM
To: Balaji Venkatraman (balajiv) mailto:bala...@cisco.com>>; 
Neale Ranns (nranns) mailto:nra...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi 

Re: [vpp-dev] VPP IPSec failed to add SA

[Balaji Venkatraman via Lists.Fd.Io]

Looking at the docs, I think you need to set one using the:

set crypto handler cipher [cipher2 cipher3 …] engine

Not sure, what’s the default behavior.
--
Regards,
Balaji.


From:  on behalf of "Ying, Ruoyu" 
Date: Thursday, October 17, 2019 at 6:03 PM
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi Neale,

Thanks for replying. I think you’ve pointed out the root cause. The cmds 
provides the response like this:
vpp# show crypto engine
No crypto engines registered
vpp# show ipsec backend
IPsec AH backends available:
   Name Index Active
  crypto engine backend   0 yes
IPsec ESP backends available:
   Name Index Active
  crypto engine backend   0 no
   dpdk backend   1 yes

Looks like that no crypto engine is registered. I’m checking the related docs, 
but are the engines registered by default or we need to manually register them? 
Thanks.

Best Regards,
Ruoyu

From: vpp-dev@lists.fd.io  On Behalf Of Neale Ranns via 
Lists.Fd.Io
Sent: Thursday, October 17, 2019 8:36 PM
To: Ying, Ruoyu ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP IPSec failed to add SA

Hi Ruoyo,

Possiblly because your loaded crypto engine/backend does not support the 
requested algorithms. Please provide :
  show crypto engine
  show ipsec backend

also whenever asking for assistance:
  sh version

Thanks,
neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of "Ying, 
Ruoyu" mailto:ruoyu.y...@intel.com>>
Date: Thursday 17 October 2019 at 10:52
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] VPP IPSec failed to add SA

Hi,

I tried to use vpp to enable IPSec in my environment. And when I tried to 
create a SA, I always got an error for that.
Detailed configs look like this:
Interface details:
vpp# show int
Name  IdxState  MTU 
(L3/IP4/IP6/MPLS) Counter  Count
VirtualFunctionEthernet0/5/0  1  up  9000/0/0/0
VirtualFunctionEthernet0/6/0  2  up  9000/0/0/0
local00 down  0/0/0/0

IPSec configs:

set interface state VirtualFunctionEthernet0/5/0 up
set interface state VirtualFunctionEthernet0/6/0 up

set interface ip address VirtualFunctionEthernet0/5/0 192.168.70.100/24
set interface ip address VirtualFunctionEthernet0/6/0 192.168.100.3/24

set int promiscuous on VirtualFunctionEthernet0/5/0
set int promiscuous on VirtualFunctionEthernet0/6/0

set ip arp VirtualFunctionEthernet0/6/0 192.168.100.4 fa:16:3e:b3:8b:fd
set ip arp VirtualFunctionEthernet0/5/0 192.168.70.200 fa:16:3e:f5:2f:e9

ip route add count 1 104.0.0.0/32 via 192.168.100.4 VirtualFunctionEthernet0/6/0
ip route add count 1 004.0.0.0/32 via 192.168.70.200 
VirtualFunctionEthernet0/5/0

ipsec spd add 1
set interface ipsec spd VirtualFunctionEthernet0/6/0 1
ipsec sa add 1 spi 1001 esp tunnel-src 192.168.100.3 tunnel-dst 192.168.100.4 
crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 integ-key 
6867666568676665686766656867666568676669 integ-alg sha1-96  //This line will 
return an error ‘ipsec sa: failed’
ipsec sa add 2 spi 25500128 esp tunnel-src 192.168.100.4 tunnel-dst 
192.168.100.3 crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg 
aes-cbc-128 integ-key 6867666568676665686766656867666568676669 integ-alg sha1-96
ipsec policy add spd 1 outbound priority 100 action protect sa 1 
remote-ip-range 104.0.0.0-104.0.0.0
ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass
ipsec policy add spd 1 inbound priority 100 action protect sa 1 remote-ip-range 
004.0.0.0-004.0.0.0
ipsec policy add spd 1 inbound priority 90 protocol 50 action bypass

Anyone know the cause for that? Thanks a lot!!

Best Regards,
Ruoyu

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14223): https://lists.fd.io/g/vpp-dev/message/14223
Mute This Topic: https://lists.fd.io/mt/34696319/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] VPP IPSec failed to add SA

[Balaji Venkatraman via Lists.Fd.Io]

Hi Ruoyu,
Could you please post the ipsec error message on create?
SA create usually indicates an issue with hardware. You might want to try if 
rebooting the instance resolves it?

--
Regards,
Balaji.


From:  on behalf of "Ying, Ruoyu" 
Date: Thursday, October 17, 2019 at 1:51 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP IPSec failed to add SA

Hi,

I tried to use vpp to enable IPSec in my environment. And when I tried to 
create a SA, I always got an error for that.
Detailed configs look like this:
Interface details:
vpp# show int
Name  IdxState  MTU 
(L3/IP4/IP6/MPLS) Counter  Count
VirtualFunctionEthernet0/5/0  1  up  9000/0/0/0
VirtualFunctionEthernet0/6/0  2  up  9000/0/0/0
local00 down  0/0/0/0

IPSec configs:

set interface state VirtualFunctionEthernet0/5/0 up
set interface state VirtualFunctionEthernet0/6/0 up

set interface ip address VirtualFunctionEthernet0/5/0 192.168.70.100/24
set interface ip address VirtualFunctionEthernet0/6/0 192.168.100.3/24

set int promiscuous on VirtualFunctionEthernet0/5/0
set int promiscuous on VirtualFunctionEthernet0/6/0

set ip arp VirtualFunctionEthernet0/6/0 192.168.100.4 fa:16:3e:b3:8b:fd
set ip arp VirtualFunctionEthernet0/5/0 192.168.70.200 fa:16:3e:f5:2f:e9

ip route add count 1 104.0.0.0/32 via 192.168.100.4 VirtualFunctionEthernet0/6/0
ip route add count 1 004.0.0.0/32 via 192.168.70.200 
VirtualFunctionEthernet0/5/0

ipsec spd add 1
set interface ipsec spd VirtualFunctionEthernet0/6/0 1
ipsec sa add 1 spi 1001 esp tunnel-src 192.168.100.3 tunnel-dst 192.168.100.4 
crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-128 integ-key 
6867666568676665686766656867666568676669 integ-alg sha1-96  //This line will 
return an error ‘ipsec sa: failed’
ipsec sa add 2 spi 25500128 esp tunnel-src 192.168.100.4 tunnel-dst 
192.168.100.3 crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg 
aes-cbc-128 integ-key 6867666568676665686766656867666568676669 integ-alg sha1-96
ipsec policy add spd 1 outbound priority 100 action protect sa 1 
remote-ip-range 104.0.0.0-104.0.0.0
ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass
ipsec policy add spd 1 inbound priority 100 action protect sa 1 remote-ip-range 
004.0.0.0-004.0.0.0
ipsec policy add spd 1 inbound priority 90 protocol 50 action bypass

Anyone know the cause for that? Thanks a lot!!

Best Regards,
Ruoyu

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14194): https://lists.fd.io/g/vpp-dev/message/14194
Mute This Topic: https://lists.fd.io/mt/34696319/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] Basic l2 bridging does not work

[Balaji Venkatraman via Lists.Fd.Io]

Hi Chuan,

Could you please try to reset the ixia controller connected to port 4?
I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I 
suspect the ixia port.

--
Regards,
Balaji.


From: Chuan Han 
Date: Thursday, October 17, 2019 at 11:09 AM
To: "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" , Arivudainambi Appachi gounder 
, Jerry Cen 
Subject: Re: [vpp-dev] Basic l2 bridging does not work

Yes. It is unidirectional stream from port 1 to port 4.

Another engineer, Nambi, configured ixia. What he showed me yesterday is that 
xia port connected to port 1 is green and good. ixia port connected to port 4 
is green but has a red exclamation mark, which means ping does not work.

We also found eth0 on R230 is down shown by "show hardware eth0" command. 
However "show int" shows it is up.


vpp# sh hardware-interfaces eth0
  NameIdx   Link  Hardware
eth0   2down  eth0
  Link speed: unknown
  Ethernet address b4:96:91:23:1e:d6
  Intel 82599
carrier down
flags: admin-up promisc pmd rx-ip4-cksum
rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)
tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0
max rx packet len: 15872
promiscuous: unicast on all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   macsec-strip vlan-filter vlan-extend jumbo-frame scatter
   security keep-crc
rx offload active: ipv4-cksum
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso macsec-insert multi-segs security
tx offload active: none
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp
   ipv6-udp ipv6-ex ipv6
rss active:none
tx burst function: (nil)
rx burst function: ixgbe_recv_pkts_vec

rx frames ok   33278
rx bytes ok  3960082
extended stats:
  rx good packets  33278
  rx good bytes  3960082
  rx q0packets 33278
  rx q0bytes 3960082
  rx size 65 to 127 packets33278
  rx multicast packets 33278
  rx total packets 33278
  rx total bytes 3960082
vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 rx packets  
   33279
rx bytes
 3960201
drops   
   5
punt
   1
tx-error
   33274
eth1  1  up  9000/0/0/0 rx packets  
   33274
rx bytes
 3959606
tx packets  
   33273
tx bytes
 3959487
drops   
   33274
tx-error
   3
local00 down  0/0/0/0
vpp#

On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
Hi Chuan,

I assume u have unidirectional stream ? ixia->1->2->3->4->ixia?

vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 rx packets  
   30925
rx bytes
 3680075
drops   
   5
punt
   1
tx-error
   30920
eth1  1  up  9000/0/0/0 rx packets  
   30920 <<< packets are received on port 3
rx bytes
   

Re: [vpp-dev] Basic l2 bridging does not work

[Balaji Venkatraman via Lists.Fd.Io]

Hi Chuan,

I assume u have unidirectional stream ? ixia->1->2->3->4->ixia?

vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 rx packets  
   30925
rx bytes
 3680075
drops   
   5
punt
   1
tx-error
   30920
eth1  1  up  9000/0/0/0 rx packets  
   30920 <<< packets are received on port 3
rx bytes
 3679480
tx packets  
   30919
tx bytes
 3679361
drops   
   30920 <<< all dropped at port 3
tx-error
   3
local00 down  0/0/0/0


On sh error logs on R 230 we see
 1 ethernet-input l3 mac mismatch 
 3   eth1-output  interface is down
 30922   eth0-output  interface is down



Do u see the arp getting resolved on ixia? The mac on ixia at port with 
172.16.1.2/24 should be seen on its other port. Are the 
ixia ports up at both ends?


--
Regards,
Balaji.


From:  on behalf of "Chuan Han via Lists.Fd.Io" 

Reply-To: "chuan...@google.com" 
Date: Thursday, October 17, 2019 at 9:59 AM
To: "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Basic l2 bridging does not work

It seems R740 vpp works fine. All packets coming from port 1 go to port 2.

vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 tx packets  
   30895
tx bytes
 3676505
eth1  1  up  9000/0/0/0 rx packets  
   30895
rx bytes
 3676505
local00 down  0/0/0/0
vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 tx packets  
   30897
tx bytes
 3676743
eth1  1  up  9000/0/0/0 rx packets  
   30897
rx bytes
 3676743
local00 down  0/0/0/0
vpp# sh error
   CountNode  Reason
 30899l2-output   L2 output packets
 30899l2-learnL2 learn packets
 1l2-learnL2 learn misses
 30899l2-inputL2 input packets
 30899l2-floodL2 flood packets
vpp#

The drop happened on R230 vpp. Port 3 dropped all pkts complaining about down 
interface. However, show command shows interfaces are up.

vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 rx packets  
   30925
rx bytes
 3680075
drops   
   5
punt
   1
tx-error
   30920
eth1  1  up  9000/0/0/0 rx packets  
   30920
rx bytes
 3679480
tx packets  
   30919
tx bytes
 3679361
   

Re: [vpp-dev] Basic l2 bridging does not work

[Balaji Venkatraman via Lists.Fd.Io]

Hi Chuan,
I got the eth0 and eth1 mixed up. My bad.
Are these fiber or copper links? You may want to check if the cable is ok. 
Also, please make sure you have crossover cable(if RJ) between the servers.

Thanks!
--
Regards,
Balaji.


From: Chuan Han 
Date: Thursday, October 17, 2019 at 2:41 PM
To: "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" , Arivudainambi Appachi gounder 
, Jerry Cen 
Subject: Re: [vpp-dev] Basic l2 bridging does not work

Restarting ixia controller does not help. We ended up with both ixia ports 
having '!'.

We are not sure how ixia port plays a role here. eth0 interfaces are the 
interfaces connecting two servers, not to ixia.

On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
Hi Chuan,

Could you please try to reset the ixia controller connected to port 4?
I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I 
suspect the ixia port.

--
Regards,
Balaji.


From: Chuan Han mailto:chuan...@google.com>>
Date: Thursday, October 17, 2019 at 11:09 AM
To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi 
gounder mailto:aappa...@google.com>>, Jerry Cen 
mailto:zhiw...@google.com>>
Subject: Re: [vpp-dev] Basic l2 bridging does not work

Yes. It is unidirectional stream from port 1 to port 4.

Another engineer, Nambi, configured ixia. What he showed me yesterday is that 
xia port connected to port 1 is green and good. ixia port connected to port 4 
is green but has a red exclamation mark, which means ping does not work.

We also found eth0 on R230 is down shown by "show hardware eth0" command. 
However "show int" shows it is up.


vpp# sh hardware-interfaces eth0
  NameIdx   Link  Hardware
eth0   2down  eth0
  Link speed: unknown
  Ethernet address b4:96:91:23:1e:d6
  Intel 82599
carrier down
flags: admin-up promisc pmd rx-ip4-cksum
rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)
tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0
max rx packet len: 15872
promiscuous: unicast on all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   macsec-strip vlan-filter vlan-extend jumbo-frame scatter
   security keep-crc
rx offload active: ipv4-cksum
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso macsec-insert multi-segs security
tx offload active: none
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp
   ipv6-udp ipv6-ex ipv6
rss active:none
tx burst function: (nil)
rx burst function: ixgbe_recv_pkts_vec

rx frames ok   33278
rx bytes ok  3960082
extended stats:
  rx good packets  33278
  rx good bytes  3960082
  rx q0packets 33278
  rx q0bytes 3960082
  rx size 65 to 127 packets33278
  rx multicast packets 33278
  rx total packets 33278
  rx total bytes 3960082
vpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
eth0  2  up  9000/0/0/0 rx packets  
   33279
rx bytes
 3960201
drops   
   5
punt
   1
tx-error
   33274
eth1  1  up  9000/0/0/0 rx packets  
   33274
rx bytes
 3959606
tx packets  
   33273
tx bytes
 3959487
drops   
   33274
tx-error
   3
local00 down  0/0/0/0
vpp#

On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) 

Re: [vpp-dev] Basic l2 bridging does not work

[Balaji Venkatraman via Lists.Fd.Io]

It plays a role if it is asymmetric at both ends. You could enable it at both 
ends and check.

On Oct 17, 2019, at 3:15 PM, Chuan Han  wrote:


I rebooted the r230 machine and found the phy nic corresponding to eth has 
autoneg off.

root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1
Settings for enp6s0f1:
Supported ports: [ FIBRE ]
Supported link modes:   1baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes:  1baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes
root@esdn-relay:~/gnxi/perf_testing/r230#

On r740, autoneg is on. It is copper.

root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3
Settings for eno3:
Supported ports: [ TP ]
Supported link modes:   100baseT/Full
1000baseT/Full
1baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  100baseT/Full
1000baseT/Full
1baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes
root@esdn-lab:~/gnxi/perf_testing/r740/vpp#

not clear if this plays a role or not.

On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io 
mailto:google@lists.fd.io>> wrote:
Restarting ixia controller does not help. We ended up with both ixia ports 
having '!'.

We are not sure how ixia port plays a role here. eth0 interfaces are the 
interfaces connecting two servers, not to ixia.

On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
Hi Chuan,

Could you please try to reset the ixia controller connected to port 4?
I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I 
suspect the ixia port.

--
Regards,
Balaji.


From: Chuan Han mailto:chuan...@google.com>>
Date: Thursday, October 17, 2019 at 11:09 AM
To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi 
gounder mailto:aappa...@google.com>>, Jerry Cen 
mailto:zhiw...@google.com>>
Subject: Re: [vpp-dev] Basic l2 bridging does not work

Yes. It is unidirectional stream from port 1 to port 4.

Another engineer, Nambi, configured ixia. What he showed me yesterday is that 
xia port connected to port 1 is green and good. ixia port connected to port 4 
is green but has a red exclamation mark, which means ping does not work.

We also found eth0 on R230 is down shown by "show hardware eth0" command. 
However "show int" shows it is up.


vpp# sh hardware-interfaces eth0
  NameIdx   Link  Hardware
eth0   2down  eth0
  Link speed: unknown
  Ethernet address b4:96:91:23:1e:d6
  Intel 82599
carrier down
flags: admin-up promisc pmd rx-ip4-cksum
rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)
tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0
max rx packet len: 15872
promiscuous: unicast on all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   macsec-strip vlan-filter vlan-extend jumbo-frame scatter
   security keep-crc
rx offload active: ipv4-cksum
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso macsec-insert multi-segs security
tx offload active: none
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp
   ipv6-udp ipv6-ex ipv6
rss active:none
tx burst function: (nil)
rx burst function: ixgbe_recv_pkts_vec

rx frames ok   33278
rx bytes ok  3960082
extended stats:
  rx good packets

Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Balaji Venkatraman via Lists.Fd.Io]

[Sorry hit the ‘send’ by mistake..]

Did you try that solution?

Thanks!
--
Regards,
Balaji.


From: "Balaji Venkatraman (balajiv)" 
Date: Wednesday, February 26, 2020 at 4:46 PM
To: "Majumdar, Kausik" , vpp-dev 

Cc: "vppsb-...@lists.fd.io" 
Subject: Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures

Hi Kausik,
I see a project that incorporated FRR with VPP.

x https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP




--
Regards,
Balaji.


From:  on behalf of "Majumdar, Kausik" 

Date: Wednesday, February 26, 2020 at 4:31 PM
To: vpp-dev 
Cc: "vppsb-...@lists.fd.io" , "Majumdar, Kausik" 

Subject: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures


Hi folks,

I wanted to start a new thread on the discussion related to VPP with FRR bring 
up and get this working together for VPP as a Data plane with FRR as a Control 
/Routing plane. Please chime in if you have already got VPP and FRR working 
together or can help on the current issues.

I am currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn’t 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition of 
macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
make[1]: *** [librtnl/netns.lo] Error 1
make[1]: Leaving directory `/root/vpp/build-root/build-vpp_debug-native/netlink'
make: *** [netlink-build] Error 2

I have applied the following diff change in my local codebase and netlink 
compiled fine.

diff --git a/netlink/librtnl/netns.c b/netlink/librtnl/netns.c
index 1b40227..8ecf02b 100644
--- a/netlink/librtnl/netns.c
+++ b/netlink/librtnl/netns.c
@@ -66,7 +66,6 @@ u8 *format_ns_link (u8 *s, va_list *args)
 #define ns_foreach_rta  \
   _(RTA_DST, dst, 1)\
   _(RTA_SRC, src, 1)\
-  _(RTA_VIA, via, 1)\
   _(RTA_GATEWAY, gateway, 1)\
   _(RTA_IIF, iif, 1)\
   _(RTA_OIF, oif, 1)\
diff --git a/netlink/librtnl/rtnl.c b/netlink/librtnl/rtnl.c
index a849dc6..9879e14 100644
--- a/netlink/librtnl/rtnl.c
+++ b/netlink/librtnl/rtnl.c
@@ -266,7 +266,7 @@ static int rtnl_socket_open(rtnl_ns_t *ns)
 .nl_groups = grpmask(RTNLGRP_LINK)| grpmask(RTNLGRP_IPV6_IFADDR) |
 grpmask(RTNLGRP_IPV4_IFADDR) | grpmask(RTNLGRP_IPV4_ROUTE) |
 grpmask(RTNLGRP_IPV6_ROUTE) | grpmask(RTNLGRP_NEIGH) |
-grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
+grpmask(RTNLGRP_NOTIFY),
   };

   if (bind(ns->rtnl_socket, (struct sockaddr*) , sizeof(addr))) {


[root@localhost vpp]# ls 
/root/vpp/build-root/install-vpp_debug-native/netlink/lib64
librtnl.a   librtnl.solibrtnl.so.0.0.0   testrtnl_plugin.la  
testrtnl_plugin.so.0
librtnl.la  librtnl.so.0  testrtnl_plugin.a  testrtnl_plugin.so  
testrtnl_plugin.so.0.0.0



  1.  router build error –

Is there any fix available for the tap_inject_netlink.c failure?

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 

 Building router in /root/vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory `/root/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 

Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Balaji Venkatraman via Lists.Fd.Io]

Hi Kausik,
I see a project that incorporated FRR with VPP.

x https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP




--
Regards,
Balaji.


From:  on behalf of "Majumdar, Kausik" 

Date: Wednesday, February 26, 2020 at 4:31 PM
To: vpp-dev 
Cc: "vppsb-...@lists.fd.io" , "Majumdar, Kausik" 

Subject: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures


Hi folks,

I wanted to start a new thread on the discussion related to VPP with FRR bring 
up and get this working together for VPP as a Data plane with FRR as a Control 
/Routing plane. Please chime in if you have already got VPP and FRR working 
together or can help on the current issues.

I am currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn’t 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition of 
macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
make[1]: *** [librtnl/netns.lo] Error 1
make[1]: Leaving directory `/root/vpp/build-root/build-vpp_debug-native/netlink'
make: *** [netlink-build] Error 2

I have applied the following diff change in my local codebase and netlink 
compiled fine.

diff --git a/netlink/librtnl/netns.c b/netlink/librtnl/netns.c
index 1b40227..8ecf02b 100644
--- a/netlink/librtnl/netns.c
+++ b/netlink/librtnl/netns.c
@@ -66,7 +66,6 @@ u8 *format_ns_link (u8 *s, va_list *args)
 #define ns_foreach_rta  \
   _(RTA_DST, dst, 1)\
   _(RTA_SRC, src, 1)\
-  _(RTA_VIA, via, 1)\
   _(RTA_GATEWAY, gateway, 1)\
   _(RTA_IIF, iif, 1)\
   _(RTA_OIF, oif, 1)\
diff --git a/netlink/librtnl/rtnl.c b/netlink/librtnl/rtnl.c
index a849dc6..9879e14 100644
--- a/netlink/librtnl/rtnl.c
+++ b/netlink/librtnl/rtnl.c
@@ -266,7 +266,7 @@ static int rtnl_socket_open(rtnl_ns_t *ns)
 .nl_groups = grpmask(RTNLGRP_LINK)| grpmask(RTNLGRP_IPV6_IFADDR) |
 grpmask(RTNLGRP_IPV4_IFADDR) | grpmask(RTNLGRP_IPV4_ROUTE) |
 grpmask(RTNLGRP_IPV6_ROUTE) | grpmask(RTNLGRP_NEIGH) |
-grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
+grpmask(RTNLGRP_NOTIFY),
   };

   if (bind(ns->rtnl_socket, (struct sockaddr*) , sizeof(addr))) {


[root@localhost vpp]# ls 
/root/vpp/build-root/install-vpp_debug-native/netlink/lib64
librtnl.a   librtnl.solibrtnl.so.0.0.0   testrtnl_plugin.la  
testrtnl_plugin.so.0
librtnl.la  librtnl.so.0  testrtnl_plugin.a  testrtnl_plugin.so  
testrtnl_plugin.so.0.0.0



  1.  router build error –

Is there any fix available for the tap_inject_netlink.c failure?

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 

 Building router in /root/vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory `/root/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 
  ^
compilation terminated.
/root/vpp/build-data/../router/router/tap_inject_node.c: In function 'tap_rx':
/root/vpp/build-data/../router/router/tap_inject_node.c:182:29: error: 
'VLIB_BUFFER_DATA_SIZE' undeclared (first use in this function)
 #define MTU_BUFFERS ((MTU + VLIB_BUFFER_DATA_SIZE - 1) / 

Re: [vpp-dev] interface activation problem using VPP in Azure with DPDK failsafe interfaces #vpp #dpdk #azure

[Balaji Venkatraman via Lists.Fd.Io]

cc-Damjan who is the DPDK expert.

Not very conversant with failsafeEth. Looks like the driver isn’t able to 
connect to the device

2020/01/23 14:37:40:578 notice dpdk   EAL: Driver cannot attach the 
device (0003:00:02.0)


Here is some info I looked up regarding initializing the DPDK for Failsafe

https://dpdk.readthedocs.io/en/v17.08/nics/fail_safe.html#using-the-fail-safe-pmd-from-the-eal-command-line


HTH.

--
Regards,
Balaji.



From:  on behalf of Chris King 
Date: Thursday, January 23, 2020 at 7:28 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] interface activation problem using VPP in Azure with 
DPDK failsafe interfaces #vpp #dpdk #azure

Update: I had forgotten to modprobe (i.e. load) the ib_uverbs and mlx4_ib 
drivers which are required for my NICs on Azure. I noticed that something was 
wrong when looking at the output of 'sudo vppctl show log'. I then went back 
and tried to get DPDK's testpmd application to work and from the output there 
it pointed to the missing drivers. I did manage to get testpmd to attach to my 
drivers. However, things are still not working correctly from the VPP side 
(maybe it's the way that VPP is initializing DPDK?).

Getting back to your question, I'm not sure what you mean by the remote end of 
the FailsafeEthernet0 interface since this is a DPDK interface using the 
failsafe PMD (netvsc, in this case). The underlying hardware this device is 
related to are the eth1 and rename6 interfaces since they have the same MAC 
address and the PCI address of 0002:00:02.0:
sudo lshw -class network -businfo
Bus info  Device  Class  Description

pci@0001:00:02.0  rename5 networkMT27500/MT27520 Family 
[ConnectX-3/ConnectX-3 Pro Virtual Function]
pci@0002:00:02.0  rename6 networkMT27500/MT27520 Family 
[ConnectX-3/ConnectX-3 Pro Virtual Function]
pci@0003:00:02.0  rename7 networkMT27500/MT27520 Family 
[ConnectX-3/ConnectX-3 Pro Virtual Function]

 sudo ./dpdk-devbind.py --status

Network devices using DPDK-compatible driver



Network devices using kernel driver
===
0001:00:02.0 'MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual 
Function] 1004' if=rename5 drv=mlx4_core unused=
0002:00:02.0 'MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual 
Function] 1004' if=rename6 drv=mlx4_core unused=
0003:00:02.0 'MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual 
Function] 1004' if=rename7 drv=mlx4_core unused=

Now, if I try to bring up the interface on the link I get the following output 
in 'sudo vppctl show hardware':
vpp# show hardware
  NameIdx   Link  Hardware
FailsafeEthernet0  1 up   FailsafeEthernet0
  Link speed: 10 Gbps
  Ethernet address 00:0d:3a:f4:eb:8d
  FailsafeEthernet
carrier up full duplex mtu 1504
flags: admin-up pmd maybe-multiseg rx-ip4-cksum
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast off
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum scatter
tx offload avail:  ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs
tx offload active: multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 ipv6-tcp-ex
   ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other
   ipv6-ex ipv6
rss active:none
tx burst function: failsafe_tx_burst
rx burst function: failsafe_rx_burst
  Errors:
rte_eth_dev_start[port:0, errno:-19]: Unknown error -19

So, it's showing as up with with an error on the call to rte_eth_dev_start. Now 
'sudo vppctl show log' shows these log entries (and the attach device entries 
keep repeating):
2020/01/23 14:37:40:578 notice dpdk   net_vdev_netvsc: probably using 
routed NetVSC interface "eth1" (index 3)
2020/01/23 14:37:40:578 notice dpdk   EAL: Driver cannot attach the 
device (0002:00:02.0)
2020/01/23 14:37:40:578 notice dpdk   EAL: Failed to attach device on 
primary process
2020/01/23 14:37:40:578 notice dpdk   net_failsafe: sub_device 0 probe 
failed (No such file or directory)
2020/01/23 14:37:40:578 notice dpdk   tun_alloc(): Rx trigger disabled: 
Device or resource busy
2020/01/23 14:37:40:578 notice dpdk   net_vdev_netvsc: probably using 
routed NetVSC interface "eth2" (index 4)
2020/01/23 14:37:40:578 notice dpdk   EAL: Driver cannot attach the 
device (0003:00:02.0)
2020/01/23 14:37:40:578 notice dpdk   EAL: Failed to attach device on 
primary process
2020/01/23 14:37:40:578 notice dpdk   net_failsafe: sub_device 0 probe 
failed (File exists)
2020/01/23 14:37:40:578 notice dpdk 

Re: [vpp-dev] issue with ARP and classify packet forwarding #classify

[Balaji Venkatraman via Lists.Fd.Io]

Hi Po,

Could you ensure the memifs and the ACLs u have configured are consistent with 
the tables you have. Are all under 100?

--
Regards,
Balaji.


From:  on behalf of Po 
Date: Thursday, January 23, 2020 at 11:14 PM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] issue with ARP and classify packet forwarding #classify

Hi,

I would like to classify the packet and forward to desired destination
- Classify hits the rules
- ARP proxy enabled

Expect the acl-hits goes to [ip4-arp] then hand over to [memif0/3-output], but 
end up packet dropped with ip4-arp: no source address for ARP request

Any expert may share the what is missing from the debug CLI?

Thank you.
Po



Topology
[cid:attach_0_15ECC1408F99A7F7_12230@lists.fd.io]

Commands:
vpp# create interface memif id 2 slave
vpp# create interface memif id 3 slave
vpp# set interface state memif0/2 up
vpp# set interface state memif0/3 up
vpp# classify table mask hex 
00ff buckets 16 
skip 1
vpp# classify session opaque-index 0 table-index 0 match hex 
00060a0a02010a0a0202
 action set-ip4-fib-id 100
vpp# classify session opaque-index 1 table-index 0 match hex 
00060a0a02010a0a0203
 action set-ip4-fib-id 200
vpp# ip route add 10.10.2.2/32 table 100 via memif0/3
vpp# ip route add 10.10.2.0/24 table 100 via memif0/2
vpp# ip route add 10.10.2.0/24 via memif0/2
vpp# set int input acl intfc memif0/2 ip4-table 0
vpp# set int ip address memif0/2 10.10.2.0/24
vpp# set ip arp proxy 10.10.2.1 - 10.10.2.11
vpp# set ip arp fib-id 100 proxy 10.10.2.1 - 10.10.2.11
vpp# set interface proxy-arp memif0/2 enable
vpp# set interface proxy-arp memif0/3 enable
vpp#


vpp# show classify table

[6]: heap offset 1200, elts 2, normal
0: [1200]: next_index -1 advance 0 opaque 0 action 1 metadata 1
k: 00060a0a02010a0a0202
hits 3, last_heard 494.07


vpp# show vlib graph ip4-arp
   Name  NextPrevious
ip4-arp error-drop [0]  nsh-adj-incomplete
  memif0/3-output [1] lookup-ip4-src
lookup-ip4-dst-itf
  lookup-ip4-dst
mpls-adj-incomplete
tcp4-output
bfd-udp-echo4-input
  bfd-udp4-input
 ip4-punt-redirect
 ip4-load-balance
ip4-lookup
   ip4-classify
vpp# show ip fib index 1
ipv4-VRF:100, fib_index:1, flow hash:[src dst sport dport proto ] 
locks:[src:classify:1, ]
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:7 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:8 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.2.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:20 buckets:1 uRPF:18 to:[0:0]]
[0] [@4]: ipv4-glean: memif0/2: mtu:9000 02fea803ab310806
10.10.2.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:22 to:[0:0]]
[0] [@2]: dpo-receive
10.10.2.2/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:17 to:[3:180]]
[0] [@3]: arp-ipv4: via 10.10.2.2 memif0/3
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:10 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:9 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:11 to:[0:0]]
[0] [@0]: dpo-drop ip4



Trace
Packet 12

00:08:13:344609: memif-input
  memif: hw_if_index 1 next-index 4
slot: ring 0
00:08:13:344620: ethernet-input
  IP4: b2:5f:84:5e:0b:43 -> 02:fe:a8:03:ab:31
00:08:13:344628: ip4-input
  TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xbb1c
fragment id 0x6789, flags DONT_FRAGMENT
  TCP: 59057 -> 12345
seq. 0x692e832e ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0xf2cc
00:08:13:344634: ip4-inacl
  INACL: sw_if_index 1, next_index 1, table 0, offset 1200
00:08:13:344639: ip4-lookup
  fib 1 dpo-idx 0 flow hash: 0x
  TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 

Re: [vpp-dev] interface activation problem using VPP in Azure with DPDK failsafe interfaces #vpp #dpdk #azure

[Balaji Venkatraman via Lists.Fd.Io]

Hi Chris,


We see ‘carrier down’ on the FailsafeEthernet0. What is the remote end to this 
interface? Could you confirm that is up as well?


vpp# show hardware
  NameIdx   Link  Hardware
FailsafeEthernet0  1down  FailsafeEthernet0
  Link speed: 10 Gbps
  Ethernet address 00:0d:3a:f4:eb:8d
  FailsafeEthernet
carrier down


Thanks!

--
Regards,
Balaji.


From:  on behalf of Chris King 
Date: Wednesday, January 22, 2020 at 11:01 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] interface activation problem using VPP in Azure with DPDK 
failsafe interfaces #vpp #dpdk #azure

As the subject indicates, I am having difficulty getting my VPP interfaces 
activating properly. I am trying to use DPDK-enabled netvsc devices with VPP in 
Ubuntu 18.04 in Azure.

I am trying to follow this guide: 
https://wiki.fd.io/view/VPP/How_To_Connect_A_PCI_Interface_To_VPP

Here is some basic info (run at the time I'm currently at when I can't get the 
VPP hardware in the 'up' state):
sudo vppctl show ver
vpp v19.08.1-release built by chris on --- at Thu Jan  9 19:08:52 UTC 2020

Excerpts from /etc/vpp/startup.conf:
unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}

dpdk {
dev 0002:00:02.0
vdev net_vdev_netvsc0,iface=eth1

dev 0003:00:02.0
vdev net_vdev_netvsc1,iface=eth2
}

ifconfig eth1
eth1: flags=4675  mtu 1500
inet6 fe80::20d:3aff:fef4:eb8d  prefixlen 64  scopeid 0x20
ether 00:0d:3a:f4:eb:8d  txqueuelen 1000  (Ethernet)
RX packets 217  bytes 82394 (82.3 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 285  bytes 79830 (79.8 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifconfig eth2
eth2: flags=4675  mtu 1500
inet6 fe80::20d:3aff:fef4:e08c  prefixlen 64  scopeid 0x20
ether 00:0d:3a:f4:e0:8c  txqueuelen 1000  (Ethernet)
RX packets 32  bytes 12192 (12.1 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 70  bytes 14263 (14.2 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vpp# show int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
FailsafeEthernet0 1  up  9000/0/0/0 rx packets  
  19
rx bytes
3914
drops   
  19
ip4 
   8
ip6 
  11
FailsafeEthernet2 2  up  9000/0/0/0
local00 down  0/0/0/0
vpp# show int addr
FailsafeEthernet0 (up):
  L3 10.4.1.5/24
FailsafeEthernet2 (up):
  L3 10.4.2.6/24
local0 (dn):
vpp# show hardware
  NameIdx   Link  Hardware
FailsafeEthernet0  1down  FailsafeEthernet0
  Link speed: 10 Gbps
  Ethernet address 00:0d:3a:f4:eb:8d
  FailsafeEthernet
carrier down
flags: admin-up pmd maybe-multiseg rx-ip4-cksum
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum scatter
tx offload avail:  ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs
tx offload active: multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 ipv6-tcp-ex
   ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other
   ipv6-ex ipv6
rss active:none
tx burst function: failsafe_tx_burst
rx burst function: failsafe_rx_burst

rx frames ok  19
rx bytes ok 3914
extended stats:
  rx good packets 19
  rx good bytes 3914
  rx q0packets19
  rx q0bytes3914
FailsafeEthernet2  2down  FailsafeEthernet2
  Link speed: 10 Gbps
  Ethernet address 00:0d:3a:f4:e0:8c
  FailsafeEthernet
carrier down
flags: admin-up pmd maybe-multiseg rx-ip4-cksum
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum scatter
tx 

Re: [vpp-dev] routing configuration other than default

[Balaji Venkatraman via Lists.Fd.Io]

Hi Sothy,

I think you need to have a default route defined in table 1.

ip route add 0.0.0.0/0 table 1 via 172.30.1.2 host-vpp1eth1

could u try that?
--
Regards,
Balaji.


From:  on behalf of sothy 
Date: Tuesday, January 21, 2020 at 9:47 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] routing configuration other than default

Hi,
I'm following the UPF-VPP development in 
https://github.com/travelping/vpp/tree/feature/1908/upf
VPP version is
 show version
vpp v19.08.1-393~g25cea519e-dirty built by root on buildkitsandbox at Tue Dec  
3 14:06:31 UTC 2019

I use the following the interfaces and routing tables.(init.conf). I dont use 
DPDK , but I used veth

ip table add 1
ip table add 2
ip6 table add 1
ip6 table add 2

create host-interface name vpp1eth0
set interface mac address host-vpp1eth0 00:0c:29:46:1f:53
set interface ip table host-vpp1eth0 1
set interface ip6 table host-vpp1eth0 1
set interface ip address host-vpp1eth0 172.30.1.2/24
set interface state host-vpp1eth0 up

create host-interface name vpp1eth1
set interface mac address host-vpp1eth1 00:50:56:86:ed:f9
set interface ip table host-vpp1eth1 2
set interface ip6 table host-vpp1eth1 2
set interface ip address host-vpp1eth1 172.31.1.2/24
set interface state host-vpp1eth1 up

create host-interface name vpp1eth2
set interface mac address host-vpp1eth2 02:fe:f5:6f:45:72
set int ip address host-vpp1eth2 172.32.1.2/24
set int state host-vpp1eth2 up

ip route add 0.0.0.0/0 table 2 via 172.31.1.2 host-vpp1eth1

upf pfcp endpoint ip 172.32.1.2 vrf 0

upf nwi name cp vrf 0
upf nwi name internet vrf 1
upf nwi name sgi vrf 2

upf gtpu endpoint ip 172.32.1.2 nwi cp teid 0x8000/2
upf gtpu endpoint ip 172.30.1.2 nwi internet teid 0x8000/2
++
When I ping from vpp,
vpp#ping 172.30.1.1
Failed: no egress interface
Failed: no egress interface
Failed: no egress interface
Failed: no egress interface
Failed: no egress interface

Statistics: 0 sent, 0 received, 0% packet loss
*
When I ping from vpp for 172.32.1.1
vpp# ping 172.32.1.1
116 bytes from 172.32.1.1: icmp_seq=1 ttl=64 time=.1633 ms
116 bytes from 172.32.1.1: icmp_seq=2 ttl=64 time=3.2511 ms
Aborted due to a keypress.

Statistics: 2 sent, 2 received, 0% packet loss
**
Based on the above test, I feel I missed something in table 1. Default routing 
table configuration is working. I wish to know what I missed in table 1

Thanks
Sothy

.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15210): https://lists.fd.io/g/vpp-dev/message/15210
Mute This Topic: https://lists.fd.io/mt/69961536/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] Check in ip4_local_inline()

[Balaji Venkatraman via Lists.Fd.Io]

Hi Nitin,
Isn’t ip_lookup based of destination ip, Could you verify if the lookup happens 
on every packet when ‘destination ip’ is the same?

--
Regards,
Balaji.


From:  on behalf of "Dave Barach via Lists.Fd.Io" 

Reply-To: "Dave Barach (dbarach)" 
Date: Friday, January 3, 2020 at 6:38 AM
To: Nitin Saxena , "vpp-dev@lists.fd.io" 

Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Check in ip4_local_inline()

Ask yourself how often there will be precisely one source (or dst) IP address 
in this path. Optimizing a specific lab/benchmark case may or may not make 
sense.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
Sent: Friday, January 3, 2020 8:02 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Check in ip4_local_inline()

Hi,

I am sending UDP termination packets to VPP interface with single source IP. I 
find that fib lookup is happening for every packet, even if source IP for 
current packet is same as last packet. Is it expected behavior? Following patch 
seems to avoid lookup for every packet.

Thanks,
Nitin

diff --git a/src/vnet/ip/ip4_forward.c b/src/vnet/ip/ip4_forward.c
index aa554ea..59edaba 100644
--- a/src/vnet/ip/ip4_forward.c
+++ b/src/vnet/ip/ip4_forward.c
@@ -1542,6 +1542,7 @@ ip4_local_check_src (vlib_buffer_t * b, ip4_header_t * 
ip0,
   last_check->src.as_u32 = ip0->src_address.as_u32;
   last_check->lbi = lbi0;
   last_check->error = *error0;
+  last_check->first = 0;
 }
   else
 {
@@ -1549,7 +1550,6 @@ ip4_local_check_src (vlib_buffer_t * b, ip4_header_t * 
ip0,
vnet_buffer (b)->ip.adj_index[VLIB_TX];
   vnet_buffer (b)->ip.adj_index[VLIB_TX] = last_check->lbi;
   *error0 = last_check->error;
-  last_check->first = 0;
 }
}

@@ -1638,6 +1638,7 @@ ip4_local_check_src_x2 (vlib_buffer_t ** b, ip4_header_t 
** ip,
   last_check->src.as_u32 = ip[1]->src_address.as_u32;
   last_check->lbi = lbi[1];
   last_check->error = error[1];
+  last_check->first = 0;
 }
   else
 {
@@ -1651,7 +1652,6 @@ ip4_local_check_src_x2 (vlib_buffer_t ** b, ip4_header_t 
** ip,

   error[0] = last_check->error;
   error[1] = last_check->error;
-  last_check->first = 0;
 }
}



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15035): https://lists.fd.io/g/vpp-dev/message/15035
Mute This Topic: https://lists.fd.io/mt/69397810/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] Discrepancies between CI jobs and s5ci

[Balaji Venkatraman via Lists.Fd.Io]

I agree with Damjan on this.

Seems convoluted to comprehend and enhance the suite. I think, it isn’t very 
intuitive. But I guess we are tied to python to interface with the tools 
(scapy, trex, blah for traffic profiles)?


--
Regards,
Balaji.


From:  on behalf of "Damjan Marion via Lists.Fd.Io" 

Reply-To: "dmar...@me.com" 
Date: Sunday, December 29, 2019 at 11:21 AM
To: "Dave Barach (dbarach)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci


+1, simple is key here

I think that we simply should remove that tap test as it falls under device 
driver tests which we don't test in make test framework.

PS I really don't like direction where test framework is going,
originally it was very simple to write tests even without having python 
knowledge, it was simple copy/paste learn ty example exercise.
Today you need to have advanced python skills even to understand what tests 
does. As i don't have any intention to grow my python skills, I can only 
declare myself as not capable to write any test case...

--
Damjan


On 29 Dec 2019, at 20:09, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:

I would just as soon keep the story as simple as possible. “sudo make 
test[-debug]” => run both test-runner and vpp privileged. “make test[-debug]” 
means run neither one privileged.

FWIW... Dave

From: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Sent: Saturday, December 28, 2019 12:22 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: Andrew Yourtchenko mailto:ayour...@gmail.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci

Hi Dave.

If you don't mind, would you clarify your statement further?  Is it your desire 
that 'make test[-debug]' be launched without privileges, or
is it that since VPP is a userspace application, you want to verify 
functionality without any further dependencies on the kernel creeping in?

The reason I'm asking is that because since you are aware of how the framework 
tightly couples the permissions of the test runner and
the forked VPP process, you know that launching the test runner without 
privileges is the current way we ensure that VPP runs without privileges.
We could have the runner run privileged and drop the capabilities of the forked 
VPP process by default.
Today, 'make run' runs vpp under sudo.

My thought is that a test needing additional capabilities could set a class 
attribute of say capabilities = ['cap_net_admin'] and
we could add that capability for the single test suite and report accordingly. 
Something like:


TAP Test Case

[W173] Create TAP interface fails with insufficient permissions 
 0.00 OK
[W173] Connect to existing TAP interface
 0.00 OK

TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.22 OK



If the runner is running unprivileged, we would skip:


TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.00 SKIP [ runner can't grant necessary capabilities. ]


On Sat, Dec 28, 2019 at 7:44 AM Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
My $0.02: I would like “make test[-debug]” to work without privileges.

Thanks... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Friday, December 27, 2019 7:21 PM
To: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci



On 27 Dec 2019, at 22:48, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>> wrote:
Hi Andrew.
That was the test that caught my attention.  I am of the opinion that s5ci 
provides the behavior we expect.

I personally has requested the tap test in its time to be moved to extended 
tests, because of this.

I presume the parties who made it appear in the standard tests will either 
chime into this discussion with their reasoning or will make it disappear :-)


I have a changeset that skips the test on s5ci instead of failing [0], but I 
actually think that the proper test 

Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

[Balaji Venkatraman via lists.fd.io]

As Neale replied earlier, adding L3 addr to the interface should implicitly 
enable arp on it.

Thanks!

--
Regards,
Balaji.


From: Mrityunjay Kumar 
Date: Friday, May 15, 2020 at 7:19 AM
To: "Balaji Venkatraman (balajiv)" 
Cc: Laurent Dumont , vpp-dev 
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hi  Balaji
Its working for me. I was just trying to help "Laurent Dumont"

--
@Laurent Dumont,   can try it, even this arp 
issue, is it working for you if you are adding neghbor IP?

 set ip neighbor  set ip neighbor [del]  
  [static] [no-fib-entry] [count ] [fib-id 
] [proxy  - ]
vpp#

Please try it with adding route and arp.

you can also use this, to set vlan on vf.
#ip link set eth0 vf 18 valn 101  --> u not required to create vlan interface 
in vpp.



Regards,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Fri, May 15, 2020 at 6:59 PM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
Hi Mrityunjay,

Could you try adding an ip route and recheck.

I think ARP is enabled once ip routing is enabled.

Thanks

--
Regards,
Balaji.


From: mailto:vpp-dev@lists.fd.io>> on behalf of Laurent 
Dumont mailto:laurentfdum...@gmail.com>>
Date: Friday, May 15, 2020 at 4:57 AM
To: Mrityunjay Kumar mailto:kumarn...@gmail.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hi everyone!

Thank you for the tips

The VF is created with the Trust On and spoofcheck disabled during the instance 
creation.

vf 18 MAC fa:16:3e:92:30:f1, spoof checking off, link-state auto, trust on

I had a change to test this a bit more. It looks like the issue is specifically 
with passing tagged traffic between the TOR and VPP.

I've added the VLAN101 on the TOR and the following on the VPP side.

set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

But now, if I look at the packets in error.

vpp# show error
   CountNode  Reason
 5   dpdk-input   no error
   451  arp-disabled  ARP Disabled on this interface

Is there a way to "enable" ARP on the l3 interface?


On Fri, May 15, 2020 at 1:59 AM Mrityunjay Kumar 
mailto:kumarn...@gmail.com>> wrote:

This issue, we have seen on centos as well. Just for work around,

ip link set promisc on eth0   #[eth0 ---  PF interface]
ip link set eth00 vf 0 spoofchk off   #[give your vf id ]
ip link set eth0 vf 0 trust on,

, But you will see other packet on vpp VF interface as well.

Can you try with IPv6, you will see more surprises. :)
//MJ

Regards,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Fri, May 15, 2020 at 7:55 AM Laurent Dumont 
mailto:laurentfdum...@gmail.com>> wrote:
Hi!

I was doing some initial experimentation with VPP/SRIOV/DPDK and I just wanted 
to see if some of the things I was experiencing we're expected. I was looking 
at understanding the baseline behavior for something like VPP + DPDK.

I have a small test POC with the following topology.

VM Ubuntu 18.04( with the "linux-image-extra-virtual" package) --->  (VPP + 
DPDK + IP address on the VPP interface) ---> VF ---> PF (compute with SRIOV on 
X710 cards) ---> TOR interface - untagged.

What I am seeing :

  1.  VPP is telling me I have both RX and TX packets.
  2.  That said, no ARP entry for the TOR is seen on VPP
  3.  The interface on the TOR is also not seeing any ARP entry for the VPP 
interface. The TOR is also indicating that RX and TX packets are present.
Are there any inherent limitations to the ARP with VPP/DPDK?

One weird thing is that trying to show the ARP from VPP doesn't seem to be a 
valid command :
vpp# sh ip arp
show ip: unknown input `arp'

Here are some more debugging output.

vpp# show version
vpp v20.01-release built by root on 980ae64453f3 at 2020-01-29T22:13:47

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
  L3 1.2.3.4/31


vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
carrier up full duplex mtu 9206
flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.00 numa 0
max rx 

Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

[Balaji Venkatraman via lists.fd.io]

Hi Mrityunjay,

Could you try adding an ip route and recheck.

I think ARP is enabled once ip routing is enabled.

Thanks

--
Regards,
Balaji.


From:  on behalf of Laurent Dumont 

Date: Friday, May 15, 2020 at 4:57 AM
To: Mrityunjay Kumar 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hi everyone!

Thank you for the tips

The VF is created with the Trust On and spoofcheck disabled during the instance 
creation.

vf 18 MAC fa:16:3e:92:30:f1, spoof checking off, link-state auto, trust on

I had a change to test this a bit more. It looks like the issue is specifically 
with passing tagged traffic between the TOR and VPP.

I've added the VLAN101 on the TOR and the following on the VPP side.

set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

But now, if I look at the packets in error.

vpp# show error
   CountNode  Reason
 5   dpdk-input   no error
   451  arp-disabled  ARP Disabled on this interface

Is there a way to "enable" ARP on the l3 interface?


On Fri, May 15, 2020 at 1:59 AM Mrityunjay Kumar 
mailto:kumarn...@gmail.com>> wrote:

This issue, we have seen on centos as well. Just for work around,

ip link set promisc on eth0   #[eth0 ---  PF interface]
ip link set eth00 vf 0 spoofchk off   #[give your vf id ]
ip link set eth0 vf 0 trust on,

, But you will see other packet on vpp VF interface as well.

Can you try with IPv6, you will see more surprises. :)
//MJ

Regards,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Fri, May 15, 2020 at 7:55 AM Laurent Dumont 
mailto:laurentfdum...@gmail.com>> wrote:
Hi!

I was doing some initial experimentation with VPP/SRIOV/DPDK and I just wanted 
to see if some of the things I was experiencing we're expected. I was looking 
at understanding the baseline behavior for something like VPP + DPDK.

I have a small test POC with the following topology.

VM Ubuntu 18.04( with the "linux-image-extra-virtual" package) --->  (VPP + 
DPDK + IP address on the VPP interface) ---> VF ---> PF (compute with SRIOV on 
X710 cards) ---> TOR interface - untagged.

What I am seeing :

  1.  VPP is telling me I have both RX and TX packets.
  2.  That said, no ARP entry for the TOR is seen on VPP
  3.  The interface on the TOR is also not seeing any ARP entry for the VPP 
interface. The TOR is also indicating that RX and TX packets are present.
Are there any inherent limitations to the ARP with VPP/DPDK?

One weird thing is that trying to show the ARP from VPP doesn't seem to be a 
valid command :
vpp# sh ip arp
show ip: unknown input `arp'

Here are some more debugging output.

vpp# show version
vpp v20.01-release built by root on 980ae64453f3 at 2020-01-29T22:13:47

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
  L3 1.2.3.4/31


vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
carrier up full duplex mtu 9206
flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.00 numa 0
max rx packet len: 9728
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
   outer-ipv4-cksum vlan-filter jumbo-frame scatter
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
   gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other 
ipv6-frag
   ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
rss active:none
tx burst function: i40e_xmit_pkts
rx burst function: i40e_recv_scattered_pkts_vec_avx2

tx frames ok  36
tx bytes ok 1512
rx frames ok  26
rx bytes ok 3014
extended 

Re: (Q about fixing endianness bugs in handlers) Re: [vpp-dev] Proposal for VPP binary API stability

[Balaji Venkatraman via lists.fd.io]

Hi Andrew,



“

An API that is not touched during a "make test" can not be moved

beyond the "in-progress" status. Adding the unit test implies the

commitment from the API contributor to follow the option (5) above

even for "trivial endianness bugs".

“



Absolutely essential! More so, after a change to the API.





Thanks!



--

Regards,

Balaji.





On 5/15/20, 7:20 AM, "vpp-dev@lists.fd.io on behalf of Andrew Yourtchenko" 
 wrote:



There's a very interesting couple of gerrit changes that just came in

today that is worth discussing,

and they are a perfect case study to further clarify the process - so

I tweaked the subject accordingly..

The API message itself is relatively minor, but regardless of what is

agreed that makes a good case study.



Backstory:



Once upon a time on Aug 20 2019, commit 053204ab changed

sw_interface_set_rx_mode.mode from u8 to an enum, but an htonl

conversion

function didn't make it there (enums are u32 by default as far as I can 
see).



This was after the 19.08 branch pull, and it wasn't ever tackled, so

this (buggy) behavior ended being in 20.01, 20.01.1, and in the

current 20.05-rc1.



Fast forward a bit, today I was pinged about the two changes - one for

master, one for stable/2001:



https://gerrit.fd.io/r/c/vpp/+/26879 - in master - forces the enum to be a 
u8



https://gerrit.fd.io/r/c/vpp/+/26915 - in stable/2001 - adds the

htonl() call and changes the existing ("buggy")

 behavior in the 20.01.2 - thus would silently break any API consumers

that coded against the previous "buggy" behavior.



And then we have a question open about stable/2005, which "by the

letter" can potentially accept only the second approach, since it is

past the API freeze.



Additional bit: this API is not touched in make test, so this bug had

slipped through.



So there are the following options:



1) Merge both patches, and treat the 20.05 similar to 20.01, thus

making a "silent change" in both, but making the master look closer to

a 19.08 format.



2) Leave the 20.05 and 20.01 alone with the "buggy" behavior, and

merge the master patch that shrinks the enum down to 1 byte



3) Merge the 20.01 and cherry-pick it to master and 2005 - fixing the

endianness of the u32 enum everywhere, but making an effective "silent

change" in 20.01&20.05



4)  merge the patch in master that shrinks the enum down to one byte,

and cherry-pick it to 20.01 and 20.05 - thus breaking the contract of

   "no api changes" but at least this gets to be explicitly visible early

on.



5) under the current proposal, if the API message is defined as

"production" then there would need to be a new "in-progress" message

in master with either of the two fixes, the buggy message would need

to be marked as "deprecated".  And under the current proposal by the

20.09 the "in-progress" message would become "production", the current

message would be shown as "deprecated",  to be deleted in 21.01.



So, the feedback that I would appreciate on the above:



1) the least worst course of action "right now", for this particular

issue. I discussed this with Ole and we have different opinions, so I

would like the actual API users to chime in. Please tell me which is

the least worst option from your point of view :-)



2) What is the best course of action in the future. Note, this is also

the simpler case in that there is a way to trigger a CRC-affecting

change by forcing the enum to be a u8. What would have been the best

course of action if it was simply a missing ntohl() for a field that

noone complained about for 1.5 releases. Can we assume that no-one

used that API and "fix the representation" ?



3) would there be an interest in having a sort of registry of "who

wants to know about things related to each API" - so that if a bug

like this arises that requires a behavior change to fix, I could poll

the affected folks and maybe be able to get away with (1) or (3) from

above ?



And a tweak to the process (and potentially tooling) with regards to

going to "production API status":



An API that is not touched during a "make test" can not be moved

beyond the "in-progress" status. Adding the unit test implies the

commitment from the API contributor to follow the option (5) above

even for "trivial endianness bugs".



Thoughts ?



--a









On 5/14/20, Christian Hopps  wrote:

> API stability is borderline critical for a project like VPP I think. Yes, 
it

> can be used stand-alone, but real value is added by building products on 
top

> of it.

>

> Also important is having an API framework that allows for

> backward-compatible changes to the API for making improvements.

Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

[Balaji Venkatraman via lists.fd.io]

Hi Laurent,

Trying to understand your setup:

Do you have :
  100.100.101.x/24
TOR[.1] <>[.2] VLAN

So, is the interface on TOR end also on a vlan (with same id)?


--
Regards,
Balaji.


From: Laurent Dumont 
Date: Tuesday, May 19, 2020 at 4:58 PM
To: "Balaji Venkatraman (balajiv)" 
Cc: Mrityunjay Kumar , vpp-dev 
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hey everyone,

Thank you for all the comments. Just trying to work my way through it! :)

Just as a sanity check, here is what it looks like on a fresh VPP (without any 
config).

# Configure the VPP client with the proper vlan and IP address.
set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

I then have the following :
vpp# show interface address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

TOR IP : 100.100.101.1 - VLAN 101
vpp# ping 100.100.101.1

Statistics: 5 sent, 0 received, 100% packet loss

vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
carrier up full duplex mtu 9206  promisc
flags: admin-up promisc pmd maybe-multiseg subif tx-offload 
intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.00 numa 0
max rx packet len: 9728
promiscuous: unicast on all-multicast on
vlan offload: strip off filter on qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
   outer-ipv4-cksum vlan-filter jumbo-frame scatter
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
   gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other 
ipv6-frag
   ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
rss active:none
tx burst function: i40e_xmit_pkts
rx burst function: i40e_recv_scattered_pkts_vec_avx2

tx frames ok   5
tx bytes ok  230
rx frames ok   5
rx bytes ok  320
extended stats:
  rx good packets  5
  tx good packets  5
  rx good bytes  320
  tx good bytes  230
  rx bytes   320
  rx unicast packets   5
  tx bytes   230
  tx broadcast packets 5
local0 0down  local0
  Link speed: unknown
  local
vpp# show interface address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

I can see that I have 5 packets IN (5 ARP IN and 5 replies I assume)
No output from :
vpp# show ip neighbor
vpp# show ip neighbors
vpp#

Would that basic L3 configuration be enough to ping across the TOR to VPP?

Thanks!



On Fri, May 15, 2020 at 10:47 AM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
As Neale replied earlier, adding L3 addr to the interface should implicitly 
enable arp on it.

Thanks!

--
Regards,
Balaji.


From: Mrityunjay Kumar mailto:kumarn...@gmail.com>>
Date: Friday, May 15, 2020 at 7:19 AM
To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>>
Cc: Laurent Dumont mailto:laurentfdum...@gmail.com>>, 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hi  Balaji
Its working for me. I was just trying to help "Laurent Dumont"

--
@Laurent Dumont,   can try it, even this arp 
issue, is it working for you if you are adding neghbor IP?

 set ip neighbor  set ip neighbor [del]  
  [static] [no-fib-entry] [count ] [fib-id 
] [proxy  - ]
vpp#

Please try it with adding route and arp.

you can also use this, to set vlan on vf.
#ip link set eth0 vf 18 valn 101  --> u not required to create vlan 

Re: [vpp-dev] ABF and ACL co-existence on an Interface

[Balaji Venkatraman via lists.fd.io]

Hi Venkat,

Underlying the ABF is another ACL. When we attach an ABF to the interface, the 
ACL it inherits gets applied to the interface. Not sure if another ACL 
independent of the above can be attached to the same interface. But, in any 
case, it should not crash 
Thanks!

--
Regards,
Balaji.


From:  on behalf of "vdabb...@infoblox.com" 

Date: Friday, August 7, 2020 at 9:36 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] ABF and ACL co-existence on an Interface


Hello,
Experimenting ABF in VPP. Had a question regarding the co-existence of ABF and 
ACL on an interface.
Seems like we can either attach ABF or ACL to an interface and not both.
Is this the behavior or am I missing anything?
When I try to install ABF rule on an interface that already has ACL attached, I 
see vpp resulting in a crash.
Please confirm.
thanks
Venkat
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17167): https://lists.fd.io/g/vpp-dev/message/17167
Mute This Topic: https://lists.fd.io/mt/76052836/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] ABF and ACL co-existence on an Interface

[Balaji Venkatraman via lists.fd.io]

Hi Neale,

Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?

Thanks!

--
Regards,
Balaji.


--
Regards,
Balaji.


From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew  Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.
Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.
Neale
tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew  Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Venkat,
Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?
You might want to confirm how we handle the behavior from experts here.
BTW, the second scenario you seeing the crash..
Issue 2: Delete ABF Policy that doesn’t have forwarding Path


That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?


Thanks!
—
Regards,
Balaji.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: vpp-dev@lists.fd.io  on behalf of Venkat 

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew  Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Andrew,

Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.
I will find time to translate them to make test cases soon.
Meanwhile here are the steps to reproduce the issues.


Issues 1: ABF and ACL attached to the same interface


· In vpp VAT shell and configure bunch of ACL rules in a group


vat# acl_add_replace  ipv4 permit src 30.30.30.1/32<http://30.30.30.1/32> dst 
40.40.40.1/32<http://40.40.40.1/32> sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24<http://10.10.10.0/24>, ipv4 permit+reflect src 
20.20.20.0/24<http://20.20.20.0/24>

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0


· Attach ACL Group create above to lan interface


vat# acl_interface_set_acl_list sw_if_index 1 input 0


· Following will be the state in vpp


DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#


DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32<http://30.30.30.1/32> dst 
40.40.40.1/32<http://40.40.40.1/32> proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24<http://20.20.20.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0


DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#


· Create another ACL for ABF configuration


vat# acl_add_replace  ipv4 permit src 11.11.11.0/24<http://11.11.11.0/24> proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 1


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32<http://30.30.30.1/32> dst 
40.40.40.1/32<http://40.40.40.1/32> proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24<http://20.20.20.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0

acl-index 1 count 1 tag {}

  0: ipv4 permit src 11.11.11.0/24<http://11.11.11.0/24>

Re: [vpp-dev] ABF and ACL co-existence on an Interface

[Balaji Venkatraman via lists.fd.io]

Make sense!

Thank much, Neale.

--
Regards,
Balaji.


From: "Neale Ranns (nranns)" 
Date: Wednesday, August 12, 2020 at 10:20 AM
To: "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" , Venkat 
, Andrew  Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Balaji,
Access control happens before forwarding, so the ABF plugin specifies a 
runs-after dependency on the ACL plugin
So if the same tuple is specified in the access lists used by the two features, 
then that flow is first subject to access control, then, if it is permitted, to 
forwarding.
/neale
tpyed by my fat tumhbs


From: Balaji Venkatraman (balajiv) 
Sent: Wednesday, August 12, 2020 5:08:51 PM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io ; Venkat 
; Andrew  Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Neale,



Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?



Thanks!



--

Regards,

Balaji.





--

Regards,

Balaji.





From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew  Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface





IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.

Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.

Neale

tpyed by my fat tumhbs



________

From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew  Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Venkat,

Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?

You might want to confirm how we handle the behavior from experts here.

BTW, the second scenario you seeing the crash..

Issue 2: Delete ABF Policy that doesn’t have forwarding Path



That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?





Thanks!

—

Regards,

Balaji.



Get Outlook for iOS<https://aka.ms/o0ukef>



From: vpp-dev@lists.fd.io  on behalf of Venkat 

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew  Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Andrew,



Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.

I will find time to translate them to make test cases soon.

Meanwhile here are the steps to reproduce the issues.



Issues 1: ABF and ACL attached to the same interface



• In vpp VAT shell and configure bunch of ACL rules in a group



vat# acl_add_replace  ipv4 permit src 30.30.30.1/32<http://30.30.30.1/32> dst 
40.40.40.1/32<http://40.40.40.1/32> sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24<http://10.10.10.0/24>, ipv4 permit+reflect src 
20.20.20.0/24<http://20.20.20.0/24>

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0



• Attach ACL Group create above to lan interface



vat# acl_interface_set_acl_list sw_if_index 1 input 0



• Following will be the state in vpp



DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#



DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32<http://30.30.30.1/32> dst 
40.40.40.1/32<http://40.40.40.1/32> proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24<http://20.20.20.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0



DBGvpp#

Re: [vpp-dev] VRRP issue

[Balaji Venkatraman via lists.fd.io]

Hi Naveen,

Could you try a shut/no shut on the vlan segment between the VRs?
Sometimes unreliable communication between the switches can cause the hellos to 
not be seen at other end..
Interface counters on the interface in question should help


Thanks!

--
Regards,
Balaji.


From:  on behalf of "Naveen Joy via lists.fd.io" 

Reply-To: "Naveen Joy (najoy)" 
Date: Thursday, August 13, 2020 at 3:34 PM
To: "mgsm...@netgate.com" 
Cc: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VRRP issue

Hi Matthew/All,

I am facing an issue with VRRP in VPP and would appreciate your help.

(Attached - architecture diagram)


  1.  I have 2 nodes with VPP & in each node, VRRP is configured to back up a 
router BVI interface in a bridge domain.
  2.  The VRRP VRs are speaking VRRP (multicast) over an uplink VLAN interface 
connected to an external switch.
  3.  The active router has a VR priority of 110 and is set to preempt.
The backup router has a VR priority of 100 and is not in preempt.


  1.  The issue is that VRRP in the backup router is unstable and keeps 
transitioning between the master and backup states every second.
However, the VRRP in the master node is stable.

I am running the  latest VPP release installed from master  this week.

vpp# show version verbose
Version:  v20.09-rc0~283-g40c07ce7a~b1542
Compiled by:  root
Compile host: 1f7cd9b19229
Compile date: 2020-08-11T20:40:47
Compile location: /w/workspace/vpp-merge-master-ubuntu1804
Compiler: Clang/LLVM 9.0.0 (tags/RELEASE_900/final)
Current PID:  5504

On the backup node –

Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR 
addresses on sw_if_index 11
Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Master
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR 
addresses on sw_if_index 11
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received 
advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Backup
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR 
addresses on sw_if_index 11
Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Master
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR 
addresses on sw_if_index 11
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received 
advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Backup
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR 
addresses on sw_if_index 11
Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Master
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR 
addresses on sw_if_index 11
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received 
advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] 
sw_if_index 11 VR ID 10 IPv4 transitioning to Backup
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR 
addresses on sw_if_index 11
Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting 
virtual MAC address 00:00:5e:00:01:0a on hardware interface 10

vpp# show vrrp vr
[0] sw_if_index 11 VR ID 10 IPv4
   state Backup flags: preempt no accept yes unicast no
   priority: configured 100 adjusted 100
   timers: adv interval 30 master adv 30 skew 18 master down 108
   virtual MAC 00:00:5e:00:01:0a
   addresses 10.4.4.5
   peer addresses
   tracked interfaces

vpp# show vrrp vr
[0] sw_if_index 11 VR ID 10 IPv4
   state Master flags: preempt no accept yes unicast no
   priority: configured 100 adjusted 100
   timers: adv interval 30 master adv 

Re: [vpp-dev] ABF and ACL co-existence on an Interface

[Balaji Venkatraman via lists.fd.io]

rc 11.11.11.0/24<http://11.11.11.0/24> dst 
0.0.0.0/0<http://0.0.0.0/0> proto 17 sport 0-65535 dport 0-65535


  *   Configure ABF Policy referring to the above created ACL with no 
forwarding path


DBGvpp# abf policy add id 100 acl 0

DBGvpp# show abf policy

abf:[0]: policy:100 acl:0

 path-list:[47] locks:1 flags:shared,no-uRPF, uRPF-list: None


  *   Delete ABF Policy and this results in a VPP crash


DBGvpp# abf policy del id 100 acl 0


On Fri, Aug 7, 2020 at 5:36 PM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:



On 8 Aug 2020, at 01:40, Venkat 
mailto:venkat.dabb...@gmail.com>> wrote:


Thank you Andrew for the response. Will invest time to put together the test 
cases. Could you please point me to sample test scripts for vpp for reference?

You can look in the “test” subdirectories of the ABF and acl plug-ins for the 
inspiration, hopefully should be a simple tweak to combine the two...

Or shall I compile a list of test cases I am executing using vpp dbg shell CLI 
commands?

Also, do you think there are significant changes between 1908 vs 2001 or 2005 
VPP stable branches for ABF plugin code making a case to upgrade vpp?

ACLs didn’t change for quite a while - not sure about the ABF...

You can do git log —oneline | egrep “acl|abf” on master branch to see what 
changes were there...

—a

Please advise.

thanks
Venkat


On Fri, Aug 7, 2020 at 4:25 PM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
Sure. Neither me nor Neale have k8s or ligato.

If you invest some effort into building a small “make test” script(s) that show 
the issues then:
1) it will be possible for at least one of us to take a look at them
2) they won’t resurface again.

Does this make sense?

Also, probably ligato folks have some testing as well - have you discussed with 
them what kind of scenarios they tested ?

--a

On 7 Aug 2020, at 21:35, Venkat 
mailto:venkat.dabb...@gmail.com>> wrote:


Just to give more context on my test environment... I am using contiv vpp  
Kubernetes environment and configuring ABFs via etcdctl.

eg.

/ # etcdctl --endpoints=10.43.255.42:12379<http://10.43.255.42:12379> put 
/vnf-agent/eos-branch-1/config/vpp/abfs/v2/abf/4 
'{"index":4,"acl_name":"023-sjcf

w-icmp-deny","attached_interfaces":[{"input_interface":"lan","priority":5}],"forwarding_paths":[{"interface_name":"sjc-blr-tunne

l"}]}'


Just wondering of ABF feature is mature enough in vpp. I am facing a good 
number of issues as I try to experiment with various scenarios.
I seeing issues when NAT is enabled on the interface, then ABF is not exercised.
I am not sure how to setup deny rules on the interface, if we cannot have ABF 
and ACL co-exist on the interface.
Observing crashes in VPP while performing some of these tests.


DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#

thanks
Venkat

On Fri, Aug 7, 2020 at 10:27 AM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
A contribution to “make test” that covers this scenario would be very much 
appreciated...

--a

On 7 Aug 2020, at 19:07, Venkat 
mailto:venkat.dabb...@gmail.com>> wrote:


Thank you for the response Balaji.
I have noticed VPP crashes when I configure an ABF on the interface that 
already has an non-abf ACL attached to the interface.
And when I don't have non-abf ACL, then I am able to install ABF rule. Hence 
was wondering if it's a misconfiguration to have both ABF and non-abf ACL on 
the same interface. I agree, in any case, it should not result in a crash.

thanks
Venkat


On Fri, Aug 7, 2020 at 9:59 AM Balaji Venkatraman via 
lists.fd.io<http://lists.fd.io> 
mailto:cisco@lists.fd.io>> wrote:

Hi Venkat,



Underlying the ABF is another ACL. When we attach an ABF to the interface, the 
ACL it inherits gets applied to the interface. Not sure if another ACL 
independent of the above can be attached to the same interface. But, in any 
case, it should not crash 

Thanks!



--

Regards,

Balaji.





From: mailto:vpp-dev@lists.fd.io>> on behalf of 
"vdabb...@infoblox.com<mailto:vdabb...@infoblox.com>" 
mailto:vdabb...@infoblox.com>>
Date: Friday, August 7, 2020 at 9:36 AM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] ABF and ACL co-existence on an Interface



Hello,
Experimenting ABF in VPP. Had a question regarding the co-existence of ABF and 
ACL on an interface.
Seems like we can either attach ABF or ACL to an interface and not both.
Is this the behavior or am I missing anything?
When I try to install ABF rule on an interface that already has ACL attached, I 
see vpp resulting in a crash.
Please confirm.
thanks
Venkat


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17186): https://lists.fd.io/g/vpp-dev/message/17186
Mute This Topic: https://lists.fd.io/mt/76052836/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] VPP API CRC compatibility check process in checkstyle merged and active

[Balaji Venkatraman via lists.fd.io]

Hi Andrew,

Just a few comments regarding coverage.

We could use the coverage (we currently run on a weekly basis) as baseline and 
monitor for incremental increases when a versioning change occurs. If there was 
a way to check the UT for the _v2 covers the ‘new/modified’ code and if 
possible add the coverage data as part of the commit criteria, that would be 
ideal. Until then, we could manually check if the coverage shows code for _v2 
being touched by the new test added for it before it is approved.

Just a suggestion!

--
Regards,
Balaji.


From:  on behalf of Andrew Yourtchenko 
Date: Thursday, June 18, 2020 at 8:58 AM
To: "Neale Ranns (nranns)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP API CRC compatibility check process in checkstyle 
merged and active

Hi Neale,


On 18 Jun 2020, at 17:11, Neale Ranns (nranns)  wrote:
Hi Andrew,
A couple of questions?

Absolutely! That’s how we improve it! Thanks a lot for the questions ! Replies 
inline:



Firstly, about unit testing aka make test. This is the salient passage in your 
guide:
  "foo_message_v2 is tested in "make test" to the same extent as the 
foo_message"
IMHO "to the same extent" implies everywhere v1 is used v2 should now be used 
in its place. One would hope that in most cases a simple find and replace 
through all test cases would do the job. However, once one has created such a 
fork and verified (presumably through some objective measure like lcov) that it 
is the same extent of coverage, what becomes of it? V1 and V2 APIs must 
co-exist for some time, so how do we continue to run the v1 original tests and 
the v2 fork?

For most of most of the practical use cases the _v2 will be a trivial change 
compared to _v1 (eg. field change, etc), and that it would be implemented by v1 
handler calling v2 handler,
one can start with adding the tests for v2 that touch just the new/changed 
functionality, and in that case the tests calling v1 will “count” against the 
v2 coverage without the test duplication.


https://gerrit.fd.io/r/c/vpp/+/27586 Is the fresh example of just this approach.

I discussed with Ole and I tried to make a stricter and more concise 
description here for an API change:

https://wiki.fd.io/view/VPP/ApiChangeProcess#Tooling

So I would say we can explicitly say “the tests need to be converted to use the 
new API” either at the moment of “productizing” the new API or deletion of the 
old API. And yeah the idea is that we could eventually do automatic code 
coverage tests specifically for those points to ensure it doesn’t drop (or that 
it monotonically increases :)

I am not sure there is a good way to test the “code coverage for an API” per 
se, since none of the tests have only one API - the before/after overall 
comparison should be good enough ?

Given that between any two releases multi APIs may go through a version 
upgrade, there will be many such forks to manage.

I think it should be just one per message at most ? (If one uses the 
“in-progress” transition phase for new messages - in fact we are pondering that 
it might be a good idea to also enforce that via the tool, so that would add an 
explicit “yes this is ready” phase, and avoid “accidental production status”.


Additionally, are we also going to test all combinations of messages and their 
versions, e.g. foo_v2 with bar_v2.

I think the best judgement still applies. If you have foo_v1 and bar_v1 which 
are related and replaced by foo_v2 and bar_v2, which means their deprecations  
would be probably synced, and the same would apply for the use by consumers. So 
either “v1 and v1” or “v2 and v2”.

Again - the logic behind all of this is to allow the user sitting on release X 
not using any deprecated APIs to painlessly upgrade a pre-X+1 master branch or 
the X+1 release, so they can keep their wheels turning *and* have time to fix 
the now-deprecated APIs that they use.

Having a commitment to “any version with any version” functionality - I think 
we can hold off with that commitment after we see how well the weaker promise 
works in practice.

What do you think ?



Secondly, what's the process for determining the initial categorization of 
existing APIs?

Basically, we shipped all of the APIs in the releases - so anything is a fair 
game to be a production.

Given some of the APIs are actually not used by anyone yet and need some more 
work (like IKEv2), the plan is to have a one-month grace period to 
“deproductize” the APIs:

https://wiki.fd.io/view/VPP/ApiChangeProcess#An_in-progress_API_accidentally_marked_as_.22production.22

This comes with a little bit of overhead but it gives a good visibility for the 
consumers, if there are any, to react.

We will keep this “noisy deproductize” process as well for the future to handle 
the one-off accidents (which we should have none in case we enforce the 
addition happens via in-progress state).

What do you think ?



/neale
tpyed by my fat tumhbs

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to 

Re: [vpp-dev] Dynamically adding a node between two nodes

[Balaji Venkatraman via lists.fd.io]

--
Regards,
Balaji.


From:  on behalf of Prashanth Fernando 

Date: Monday, June 8, 2020 at 10:17 PM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Dynamically adding a node between two nodes

Hi,

I am pretty new to VPP and trying to understand few things


  *   Can I add a node in middle of a packet processing graph in runtime.

Eg: In the packet graph mentioned below, if I decide to add packet validation 
in runtime

Packet processing graph from ethernet-input –> ip4-input changed to   
ethernet-input –> packet-validatation -> ip4-input





Yes, you can add in a graph node:
https://fd.io/docs/vpp/master/whatisvpp/extensible.html
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/add_plugin.html
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html







  *   Also can we have core affinity for nodes.

Say I have node-1 running in core-2 and node-2 running in core-3 etc …



Please check the vlib functionality under (Handing off buffers between threads) 
is what u looking for.
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html#handing-off-buffers-between-threads

Thanks!
--
Balaji


Request for some pointers in this regard.

Thanks in advance,
Prashanth
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16704): https://lists.fd.io/g/vpp-dev/message/16704
Mute This Topic: https://lists.fd.io/mt/74768525/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] VPP forwarding packets not destined to it #vpp

[Balaji Venkatraman via lists.fd.io]

Hi Nagaraju,

Perhaps you need to disable it on the interface in question?
Seems like it is enabled by default.

Thanks!
--
Balaji

set bridge-domain flood
Summary/usage
set bridge-domain flood  [disable].
Description
Layer 2 flooding can be enabled and disabled on each interface and on each 
bridge-domain. Use this command to manage bridge-domains. It is enabled by 
default.
Example usage
Example of how to enable flooding (where 200 is the bridge-domain-id):
vpp# set bridge-domain flood 200
Example of how to disable flooding (where 200 is the bridge-domain-id):
vpp# set bridge-domain flood 200 disable


--
Regards,
Balaji.


From:  on behalf of Nagaraju Vemuri 

Date: Wednesday, June 3, 2020 at 10:06 AM
To: "John Lo (loj)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP forwarding packets not destined to it #vpp


Hi,

We are using linux bridge to connect different interfaces owned by different 
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding 
packets to all interfaces.
Hence VPP receives some packets whose MAC address is owned by some other VPP 
instance.
We want to drop such packets. By default VPP is forwarding these packets.

We tried using "set interface l2 forward  disable", but this did not 
help.

Please suggest what we can do.

Thanks,
Nagaraju


--
Thanks,
Nagaraju Vemuri
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16639): https://lists.fd.io/g/vpp-dev/message/16639
Mute This Topic: https://lists.fd.io/mt/74640593/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

[Balaji Venkatraman via lists.fd.io]

Hi John,

I assume the pass thru/drop applies to multicast frames too(assuming we have 
IGMP enabled segment). Correct?

Thanks!

--
Regards,
Balaji.


From:  on behalf of "John Lo (loj) via lists.fd.io" 

Reply-To: "John Lo (loj)" 
Date: Wednesday, June 3, 2020 at 1:38 PM
To: Nagaraju Vemuri 
Cc: Andrew  Yourtchenko , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

We can use “show node counters” which should display counter for packets 
dropped due to MAC mismatch.  -John

From: Nagaraju Vemuri 
Sent: Wednesday, June 03, 2020 3:10 PM
To: John Lo (loj) 
Cc: Andrew  Yourtchenko ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Also, do we have any counters to validate this patch?

On Wed, Jun 3, 2020 at 11:41 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Nagaraju,

No extra config required than standard L3 setup you already have with IP 
address/subnet on your interface.  Such L3 interface should drop packets with 
unicast DMAC which does not match interface MAC.   If you can pull/clone the 
latest VPP, either master or stable/2005 branch, and build, the image should 
have my patch included.  Please let us know if it solve your problem or not.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:52 PM
To: Andrew  Yourtchenko mailto:ayour...@gmail.com>>
Cc: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Sure Andrew.
I will help with that.

Do I need to configure something in VPP with this patch to drop such packets?

Thanks,
Nagaraju


On Wed, Jun 3, 2020 at 10:48 AM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
20.05.1. The fix was ready just a little bit too late to be a safe to merge 
right at the moment of the release, so given the size of the patch and that the 
issue was there for a couple of releases already I made a call to postpone it 
till the first dot release.

As for the timing for the 20.05.1 - still TBD.

Would you be able to build the VPP in your own environment and give the 
feedback whether John’s fix addresses the issue you are seeing ?

--a

On 3 Jun 2020, at 19:23, Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>> wrote:
Thanks John.

Which release will have your fixes?


On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
I recently submitted two patches, one for master and the other for stable/2005, 
to fix an issue with L3 virtual interfaces not filter input packets with wrong 
unicast MAC address:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27311

Perhaps it is the issue you are hitting.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:06 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io

Re: [vpp-dev] Crash in ACL code while applying rulematch

[Balaji Venkatraman via lists.fd.io]

Hi Satya,

Inline..



From:  on behalf of Satya Murthy 

Date: Friday, July 17, 2020 at 3:58 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Crash in ACL code while applying rulematch

Hi Andrew,

We could not try the same test with the change you suggested.
We will try it for sure in this week.

Regarding our scenario for example:
we have 4 workers.
All the 4 workers can create ACLs and also can process data.
During high load of data and create ACLs, we are seeing this crash.
There are NO delete of ACLs done in the test.

BV: I guess, even if it is mere creation, for a brief instant between creation 
of 2 ACE, under an ACL, an ‘implicit deny’(drop packet) is assumed in data 
path. In scaled operations, in a multi worker scenario, a race condition could 
arise.. No?
--
Regards,
Balaji.


Thanks & Regards,
Murthy

As I mentioned earlier, after putting a lock around the "add acl" and 
"rulematch acl" code, issue got solved.







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16997): https://lists.fd.io/g/vpp-dev/message/16997
Mute This Topic: https://lists.fd.io/mt/75527176/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] Crash in ACL code while applying rulematch

[Balaji Venkatraman via lists.fd.io]

Hi Satya,

Rule-matching of ACL is in the data path while add/del is in control plane. If 
you NOT hitting the crash with lock in datapath, it implies the crash is 
happening during rule-matching after perhaps a delete operation of an ACE..? 
Just a possible scenario…
Thanks!
--
Regards,
Balaji.


From:  on behalf of Satya Murthy 

Date: Thursday, July 16, 2020 at 9:44 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Crash in ACL code while applying rulematch

Hi Andrew,

Thanks for your suggestions on this.

We did few more tests today, and here are some observations.
Please let us know your thoughts on this.

1) We added a lock on the datapath also while doing rulematch using acl apis.
The same lock is getting acquired while doing acl adds from other threads.

With this, we are NOT seeing the crash.

So, one question we have is:
Even when the main thread does control plane operations on ACLs ( like add / 
dels), the other workers will not be able to safely use the ACL apis to do rule 
matching ?

Taking this lock in the datapath is surely not desirable, as it will hit 
performance.
Please let us know your thoughts on this.

2) When we observed the crash earlier, we were doing only ACL adds and pumping 
data
So, the contention is between adding new ACLs and using the ACLs during 
rulematch. There are delete of ACLs at all.
This is one more observation we want to share with you, if that can give some 
hints for the crash.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16990): https://lists.fd.io/g/vpp-dev/message/16990
Mute This Topic: https://lists.fd.io/mt/75527176/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-