[vpp-dev] VPP 20.09 RC2 milestone is complete!

[Andrew Yourtchenko]

Hi all,

The VPP 20.09 RC2 milestone is complete. The artifacts are available
on packagecloud: https://packagecloud.io/app/fdio/2009/search?q=rc2

Our next milestone is on Wednesday 23rd, according to the release plan [0].

As a reminder: this release we have an extra milestone to avoid having
the fixes coming in right after the release and having to do .1, which
we can not really do due to CSIT still being busy with the release
processing.

So - for the purposes of testing, please treat the next Wednesday as
the "final" milestone with the quiet week afterwards, so that we can
get the the most out of it!

As a reminder, the draft release notes are already available for your
review/edits at:
 https://gerrit.fd.io/r/c/vpp/+/28794 - feel free to comment inline or
push your additions as new revisions. Notice I have added a bunch of
NAT-related messages which were marked as deprecated, but incorrectly,
so they were not picked up. Thanks to Ole Troan for pushing the patch
to clean up the use of "option deprecated" across the codebase, as it
took a couple of iterations to settle on its current (hopefully final)
"option deprecated" syntax.

Thanks a lot to everyone for all the hard work so far!

--a /* your friendly 20.09 release manager */

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17437): https://lists.fd.io/g/vpp-dev/message/17437
Mute This Topic: https://lists.fd.io/mt/76905173/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] ping not able to receive replies on vpp interface

[Filip Varga via lists.fd.io]

Hi Pac,

Yes the idea is that you should be able to ping NAT outside interface from the 
adjacent side of the connection. This was previously working. I will create a 
ticket for the issue and look in to it shortly.

If you have any other issues with NAT please let me know.

Best regards,
Filip

From: Pac Ette 
Sent: Wednesday, September 16, 2020 10:16 PM
To: pktno...@gmail.com
Cc: Filip Varga -X (fivarga - PANTHEON TECH SRO at Cisco) ; 
Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] ping not able to receive replies on vpp interface
Importance: High

Hi Filip,

sorry, amendment to my last email:

Your suggestion worked. But ping from linux stack (tap interface) is not 
working because there is no NAT in/out anymore.

I am using VPP with NAT. Is it not possible for ping to work with NAT?

I noticed something. If I add back:

set interface nat44 in loop0 in loop1
set interface nat44 out wan1

In addition to vpp-to-server not working, I am also unable to ping from linux 
server to vpp box.

$ ping 10.200.1.7
PING 10.200.1.7 (10.200.1.7) from 10.200.1.1 eth2: 56(84) bytes of data.
--- 10.200.1.7 ping statistics ---
80 packets transmitted, 0 received, 100% packet loss, time 80882ms

Thanks!

On Wed, Sep 16, 2020 at 1:10 PM Pac Ette via lists.fd.io 
mailto:gmail@lists.fd.io>> wrote:
Hi Filip,

Your suggestion worked. But I am using VPP with NAT. Is it not possible for 
ping to work with NAT?

I noticed something. When NAT is set, in addition to vpp to server not working, 
I am also unable to ping from linux server to vpp box.

If I add back:
set interface nat44 in loop0 in loop1
set interface nat44 out wan1

linux (10.200.1.1) --> to --> wan1 (vpp) does not work either.

Thanks!


On Wed, Sep 16, 2020 at 12:35 PM Filip Varga -X (fivarga - PANTHEON TECH SRO at 
Cisco) mailto:fiva...@cisco.com>> wrote:
Hi Pac,

Try removing from your configuration following two lines:

set interface nat44 in loop0 in loop1
set interface nat44 out wan1

Now try to ping from linux & vpp. From linux ping vpp wan interface 10.200.1.7 
and from vpp linux host 10.200.1.1 (don’t forget to specify the source 
interface, this should be your wan interface in vpp).

# ping  source 

Best regards,
Filip

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Pac Ette
Sent: Wednesday, September 16, 2020 6:14 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] ping not able to receive replies on vpp interface

Hi Dave,

I had a suspicion that my configs might be wrong. But, why would packets go 
through the NAT plugin when I am pinging from vppctl and directly on the wan1 
port - I was thinking these packets don't need to be NAT-ed. Here are my 
configs and testing results.

## Configs
cat vpp.conf
set interface state wan1 up
set interface state lan3 up
set interface state lan2 up
set interface state lan0 up

set dhcp client intfc wan1 hostname test-ccB

loopback create
set interface l2 bridge loop0 1 bvi
set interface ip address loop0 10.90.0.1/16
set interface state loop0 up

create tap id 0 host-ip4-addr 10.90.0.2/16 host-if-name 
lstack1
set interface l2 bridge tap0 1
set interface state tap0 up

loopback create
set interface l2 bridge loop1 2 bvi
set interface ip address loop1 10.100.0.1/16
set interface state loop1 up

set interface l2 bridge lan0 2
set interface l2 bridge lan2 2
set interface l2 bridge lan3 2

create tap id 1 host-ip4-addr 10.100.0.2/16 host-if-name 
lstack2
set interface l2 bridge tap1 2
set interface state tap1 up

nat44 add interface address wan1
set interface nat44 in loop0 in loop1
set interface nat44 out wan1
--
vpp# sh nat44 addresses
NAT44 pool addresses:
10.200.1.7
  tenant VRF independent
  0 busy other ports
  18 busy udp ports
  0 busy tcp ports
  0 busy icmp ports
NAT44 twice-nat pool addresses:

vpp# sh nat44 interfaces
NAT44 interfaces:
 loop0 in
 loop1 in
 wan1 out

vpp# sh dhcp client
[0] wan1 state DHCP_BOUND installed 1 addr 10.200.1.7/24 
gw 10.200.1.1 server 10.200.1.1 dns 8.8.8.8

linux stack
$ ip route
default via 10.90.0.1 dev  lstack1
10.90.0.0/16 dev lstack1 proto kernel scope link src 
10.90.0.2
10.100.0.0/16 dev lstack2 proto kernel scope link src 
10.100.0.2
--
## Testing

pings via linux stack works but pings via vppctl do not.

ping via vppctl:
vpp# ping 10.200.1.1
Statistics: 5 sent, 0 received, 100% packet loss

ping via linux stack:
$ ping 10.200.1.1
PING 10.200.1.1 (10.200.1.1) 56(84) bytes of data.
64 bytes from 10.200.1.1: icmp_seq=1 ttl=63 time=1.01 ms
64 bytes from 10.200.1.1: icmp_seq=2 ttl=63 time=0.321 ms
--- 10.200.1.1 

Re: [vpp-dev] run existing plugin in VPP

[Andrew Yourtchenko]

Excellent!

So would my guess be right that you plan to autogenerate the tests as well ?

--a

> On 17 Sep 2020, at 02:54, hem...@mnkcg.com wrote:
> 
> I did a “ps -ef | grep -I vpp” and found a few vpp processes (?) running.  I 
> killed them and then the single cdp test ran fine on using “sudo make test 
> TEST=test_cdp” from vpp root directory. 
>  
> ==
> CDP Test Case
> ==
> test_cdp_overflow_tlv (test_cdp.TestCDP) 0.28 OK
> test_cdp_underflow_tlv (test_cdp.TestCDP)0.29 OK
> test_enable_cdp (test_cdp.TestCDP)   0.23 OK
> test_send_cdp_packet (test_cdp.TestCDP)  0.28 OK
>  
> ==
> TEST RESULTS:
>  Scheduled tests: 4
>   Executed tests: 4
> Passed tests: 4
> ==
>  
> Hemant
>  
> From: hem...@mnkcg.com  
> Sent: Wednesday, September 16, 2020 7:43 PM
> To: 'ayour...@gmail.com' 
> Cc: 'vpp-dev@lists.fd.io' 
> Subject: RE: [vpp-dev] run existing plugin in VPP
>  
> Andrew,
>  
> Thanks.  I will have to play more with VPP because “sudo make test 
> TEST=test_cdp” fails.  If anyone else is able to run this test, then I know I 
> have some issues with my VPP setup or dependencies.
>  
> I found the CSIT reports – thanks!
>  
> Regarding my p4 to vpp compiler, it’s work in progress.  I will update you 
> all when something is ready for use.
>  
> Hemant 
>  
> From: vpp-dev@lists.fd.io  On Behalf Of Andrew 
> Yourtchenko
> Sent: Wednesday, September 16, 2020 7:10 PM
> To: hem...@mnkcg.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] run existing plugin in VPP
>  
> Hemant,
>  
> 
> On 17 Sep 2020, at 00:43, hem...@mnkcg.com wrote:
> 
> 
> Andrew,
>  
> Thanks!  Yes, I am a developer trying to get started with VPP. 
>  
>  
> Cool! So my “find the answer” quiz was on target :-)
>  
> 
> I run VPP using “make run-release” and get to the “vpp#” prompt.  I could do 
> a “cdp enable” and thus I know this plugin has been loaded. 
>  
> Now how to I run the packet testing in vpp/src/plugins/cdp/test/?  There is a 
> test_cdp.py in the path.  I am familiar with PTF.
>  
> “Make test-help” will give more info.
>  
> 
> Once I can run test.py for a plugin, I’d like to learn how to run performance 
> testing to see how many packets/sec of a certain size I can achieve for a 
> plugin.  What would be a good plugin to test performance with?
>  
> That’s trickier... look around  https://wiki.fd.io/view/CSIT - basically, 
> perf testing the VPP is a separate project :-) but the good thing is some 
> reports might be already there..
>  
>  
> I love the fact that you (and perhaps others) have added lua examples to 
> vpp-api.
>  
> Lua didn’t get much love for quite a while and I think would need some 
> resuscitations to work :-)
> That said, last time I had a half a day to toy  with it, in half a day I had 
> something sorta working... but don’t expect what is in the tree to be up to 
> date... it’s waiting for the folks to help it :-)
>  
> 
>  
> I am developing a compiler which ingests P4 code and outputs a VPP plugin.  
> First, I will make the compiler functionally correct to support as many P4 
> features and as many VPP features.  Then I will worry about performance which 
> is a hard problem.
>  
> This is a fun idea!
>  
> 
>  
> If you see a VPP plugin, several files can be auto-generated by compiler or 
> script.  My compiler is already generating these files:
>  
> -rw-rw-r--  1 hemant hemant   1498 Sep 16 18:38 tmp_test.c
> -rw-rw-r--  1 hemant hemant  10577 Sep 16 18:38 tmp.h
> -rw-rw-r--  1 hemant hemant  79257 Sep 16 18:38 tmp.c
> -rw-rw-r--  1 hemant hemant412 Sep 16 18:38 tmp.api
> -rw-rw-r--  1 hemant hemant250 Sep 16 18:38 CMakeLists.txt
>  
> Nice! There is the lisp script somewhere in the tree that asks questions and 
> spits out the plugin, but it’s a skeleton, with P4 one could probably go 
> quite a good bit further...
>  
> Is your compiler gonna be open source ?
>  
> —a
>  
>  
> 
>  
> Best wishes,
>  
> Hemant
>  
>  
>  
> From: Andrew  Yourtchenko  
> Sent: Wednesday, September 16, 2020 4:12 PM
> To: hem...@mnkcg.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] run existing plugin in VPP
>  
> Hey Hemant,
>  
> Welcome! :-)
> 
> Most of the plugins load automatically (default), some don’t by default.. 
> (see src/plugins/unittest/unittest.c on how it’s overridden).
>  
> You can take a look at the config required to change the defaults in 
> test/framework.py, line 422)
>  
> Looking at those places, as well as the CDP plugin, should answer the 
> question.
>  
> (I am assuming you are a developer trying to get started with VPP so trying 
> 

[vpp-dev] Lockless queue/ring buffer

[Rajith PR via lists.fd.io]

Hi All,

We are integrating a *Linux pthread* with a *vpp thread* and are looking
for a *lockless queue/ring buffer implementation* that can be used.
In vpp infra i could see fifo and ring. But not sure if they can be used
for enqueue/dequeue from a pthread that VPP is not aware off.
Do you have any reference code for such integration or any suggestions?

Thanks,
Rajith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17439): https://lists.fd.io/g/vpp-dev/message/17439
Mute This Topic: https://lists.fd.io/mt/76905306/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] ACL panics in `hash_acl_set_heap`

[Andrew Yourtchenko]

Hi Mahdi,

This patch should apply, ACL plugin had not seen much changes recently, but 
then you are not running a 20.05 anymore :-)

I would strongly suggest to evaluate on what limitations prevent you from 
following the master branch as close as possible and address them. This may 
seem daunting, but based on my experience with a dozen or so scenarios, 
following master is the most sustainable and flexible approach in the long 
term. 

With the current API compatibility process that went into action shortly past 
20.05, *if* you are using VPP as is, 20.09 should be a ~zero-cost move that you 
can evaluate (there are only 2 incompatible APIs in the “production” ones). 
(And then when you fix any usage of APIs deprecated in 20.09, 21.01 upgrade in 
the future will be similar zero-cost).

If you notice that the upgrade is painful for some reason, this will highlight 
the architectural issues/questions that need to be resolved. It’s much better 
to do it early and proactively.

—a 

> On 17 Sep 2020, at 06:01, Mahdi Varasteh  wrote:
> 
> Hi Andrew,
> 
> Thanks for you response. That makes sense. I will monitor my box memory usage.
> Unfortunately I'm using VPP 20.05. So I will try to forwardport( we have it? 
> :D) this patch to it. 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17434): https://lists.fd.io/g/vpp-dev/message/17434
Mute This Topic: https://lists.fd.io/mt/76882936/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] Issue with adding new new node in between ip4-input n ip4-lookup

[Caffeine Coder via lists.fd.io]

 Hi Dave,Thanks for tip. I enabled feature on the rx interface. It worked. 
ThanksSam M
On Tuesday, September 15, 2020, 04:16:07 AM PDT, Dave Barach via 
lists.fd.io  wrote:
 
 #yiv9801683627 #yiv9801683627 -- _filtered {} _filtered {} _filtered 
{}#yiv9801683627 #yiv9801683627 p.yiv9801683627MsoNormal, #yiv9801683627 
li.yiv9801683627MsoNormal, #yiv9801683627 div.yiv9801683627MsoNormal 
{margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv9801683627 
.yiv9801683627MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv9801683627 
div.yiv9801683627WordSection1 {}#yiv9801683627 
Sounds like you may not have enabled the “test-node” feature on the rx 
sw_if_index. “show interface  features”... Note that if the packet comes 
from a bridge group, I suspect that you’ll need to enable the feature on the 
bvi vs the rx interface.
 
  
 
This is the kind of problem which “pcap dispatch trace ...” tends to help chase 
down.
 
  
 
D.
 
  
 
From: vpp-dev@lists.fd.io  On Behalf OfCaffeine Coder via 
lists.fd.io
Sent: Tuesday, September 15, 2020 2:56 AM
To: Vpp-dev 
Subject: [vpp-dev] Issue with adding new new node in between ip4-input n 
ip4-lookup
 
  
 
Hi
 
I am trying to add a new node to parse packet data after all vxlan decoding, 
ip4-input and before doing IP lookup. This code flow is is working fine for 
packets coming from vxlan-gpe/IPSec tunnels and not for vxlan.
 
Traffic is working fine except not going through this new "test-node".
 
  
 
The issue i am seeing with vxlan packet is: packet is going directly 
ip4-lookup. i.e from ip4-vxlan-bypass->vxlan4-input->l2 
(input,learn,fwd)->ip4-input->ip4_lookup. But I can't hook my node in between 
ip4-input and ip4_lookup.
 
  
 
If I do vxlan-gpe or IPSEC, i can hook the test node properly i.e. 
ip4-vxlan-gpe-bypass->vxlan4-gpe-input->ip4-input->test-node->ip4_lookup.
 
  
 
I tried adding and changing ".runs_before" and ".runs_after" in my test-node. 
Still I am not able to stitch my test-node, if traffic coming from  vxlan 
tunnels.
 
"show vlib graph" is very useful command to debug for not able to find what 
else might be missing for vxlan. I do see that vxlan packet going through lot 
of l2 nodes. Does that need any special config for making non vpp native l3 
nodes to work fine? 
 
  
 
Any pointers will be helpful.
 
  
 
Thanks
 
Sam.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17436): https://lists.fd.io/g/vpp-dev/message/17436
Mute This Topic: https://lists.fd.io/mt/76859804/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] Question about acl match/permit behavior.

[Andrew Yourtchenko]

> On 17 Sep 2020, at 19:29, Venkat  wrote:
> 
> 
> Andrew,
> 
> I have a few follow up questions on the stated behavior. 
> 
> 1. Does the behavior you outlined about hitting special-case "-1" entries 
> apply to UDP traffic as well if the ACL rule is stateful? 

Yup.

> 
> 2. What happens when ACL config is modified while traffic is flowing? Would 
> the packets continue to hit the special-case "-1" session until the session 
> is timed out and re-claimed? If that's true, then packets would continue to 
> sneak through even when a user modifies the ACL from Permit+Reflect to Deny. 

Yep. You can look at the code, there is a debug CLI tweak to reclassify 
sessions, but I am not sure anyone actually uses it.

There is no “always right” answer to this ~20 year old question.

ACL plugin is very explicitly not a “fancy firewall”.

> 
> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL hit 
> would result in the creation of such a session and subsequent packets would 
> by-pass ACL rules and continue to be served by special-case "-1". 

...as your have observed it. The return packets on that interface matching the 
same five tuple, too.

—a

> 
> 
> thanks
> Venkat 
> 
> 
>> On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko  
>> wrote:
>> Hi Venkat,
>> 
>> Before doing ACL checks, acl-plugin checks the establshed sessions on
>> the given interface.
>> 
>> If an already established session is hit the action is set to "3" and
>> no further ACL check is done, which is what you see in your output.
>> 
>> For that case, the ACL# in the trace is a special-case "-1", same as
>> lc_index-1 - because we actually never get it to ACL lookup so do not
>> need it; and the rule# is the session index; and the trace_bits tells
>> us that this session is classifed to use timeout type "3", which is
>> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
>> sense, since you are sending the packets in one direction and thus the
>> session never establishes and the timeout type never changes to
>> "TCP_IDLE".
>> 
>> Of the packets you sent in total, 15002 packets  had hit the ACL#3
>> rule and caused the sessions to be created. The rest of the packets
>> had hit the established session entries and this is one of those that
>> you have captured.
>> 
>> At the time of taking the outputs the traffic was stopped and the
>> sessions were deleted by idle timeout (which for the transient state
>> is short).
>> 
>> Does this make sense ?
>> 
>> --a
>> 
>> 
>> 
>> 
>> On 9/14/20, Venkat  wrote:
>> > Hello Andrew,
>> >
>> > I am doing a simple test by sending TCP flows from Trex traffic generator.
>> > Traffic source is 16.0.0.1-16.0.0.100 and destination is
>> > 48.0.0.1-48.0.0.100.
>> > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
>> > Trex http profile.
>> >
>> > I have a reflective ACL to permit the flow for the above src and dst.
>> > I expect the packet to hit acl index 3 rule 0 and get permitted.
>> > However, I see the following match in the packet trace which doesn't seem
>> > like it is hitting acl index 3 and rule 0 but hitting some other acl index
>> > (acl -1 and lc_index -1).
>> > What is the behavior here? Please provide some context here..
>> >
>> > 03:47:03:874624: acl-plugin-in-ip4-fa
>> >
>> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3, match: 
>> > acl
>> > -1 rule 13309 trace_bits 80010303
>> >
>> > pkt info    
>> > 43304310
>> > 0001010600502d14 0310
>> >
>> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1 proto 6
>> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
>> > (valid) 10 rsvd 0
>> >
>> > DBGvpp# show acl-plugin acl
>> >
>> > acl-index 0 count 2 tag
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 0 dport 0
>> >
>> > 1: ipv6 deny src ::/0 dst ::/0 proto 0 sport 0 dport 0
>> >
>> > applied inbound on sw_if_index: 1
>> >
>> > applied outbound on sw_if_index:
>> >
>> > used in lookup context index: 1
>> >
>> > acl-index 1 count 6 tag
>> > {9-sra-inbound-sasefwpro-sase-default-fw-profile}
>> >
>> > 0: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport 0-65535
>> > dport 0-65535
>> >
>> > 1: ipv6 permit+reflect src ::/0 dst ::/0 proto 6 sport 0-65535 dport
>> > 0-65535
>> >
>> > 2: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport 0-65535
>> > dport 0-65535
>> >
>> > 3: ipv6 permit+reflect src ::/0 dst ::/0 proto 17 sport 0-65535 dport
>> > 0-65535
>> >
>> > 4: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535
>> > dport 0-65535
>> >
>> > 5: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535
>> > dport 0-65535
>> >
>> > applied inbound on sw_if_index: 1
>> >
>> > applied outbound on sw_if_index:
>> >
>> > used in lookup context index: 1
>> >
>> > acl-index 2 count 6 tag
>> 

Re: [vpp-dev] Question about acl match/permit behavior.

[Andrew Yourtchenko]

> On 17 Sep 2020, at 21:21, Venkat  wrote:
> 
> 
> Thanks, Andrew, 
> 
> And I noticed that sessions get deleted/reclaimed when ACL is disassociated 
> from the interface to which it was attached prior. 
> Maybe that's one option to have ACL detach and reattach to the interface when 
> there is any modification to the ACL to have immediately expected behavior 
> instead of waiting for the sessions to reclaim and reclassify. 

It’s an option I considered and specifically discarded. I think there are folks 
(at least in test) running millions of connections. You don’t want to  swoop 
all these connections all at once when you are changing an ACL and potentially 
recreate them all at once again.

Of course, if you contribute the code that replaces the reclassification with 
your suggested approach and you have data that it improves the performance in 
at least some cases and doesn’t degrade it in the others - I will be very happy 
to discuss it. :-)

—a

> 
> thanks
> Venkat
> 
>> On Thu, Sep 17, 2020 at 10:39 AM Andrew  Yourtchenko  
>> wrote:
>> 
>> 
 On 17 Sep 2020, at 19:29, Venkat  wrote:
 
>>> 
>>> Andrew,
>>> 
>>> I have a few follow up questions on the stated behavior. 
>>> 
>>> 1. Does the behavior you outlined about hitting special-case "-1" entries 
>>> apply to UDP traffic as well if the ACL rule is stateful? 
>> 
>> Yup.
>> 
>>> 
>>> 2. What happens when ACL config is modified while traffic is flowing? Would 
>>> the packets continue to hit the special-case "-1" session until the session 
>>> is timed out and re-claimed? If that's true, then packets would continue to 
>>> sneak through even when a user modifies the ACL from Permit+Reflect to 
>>> Deny. 
>> 
>> Yep. You can look at the code, there is a debug CLI tweak to reclassify 
>> sessions, but I am not sure anyone actually uses it.
>> 
>> There is no “always right” answer to this ~20 year old question.
>> 
>> ACL plugin is very explicitly not a “fancy firewall”.
>> 
>>> 
>>> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL hit 
>>> would result in the creation of such a session and subsequent packets would 
>>> by-pass ACL rules and continue to be served by special-case "-1". 
>> 
>> ...as your have observed it. The return packets on that interface matching 
>> the same five tuple, too.
>> 
>> —a
>> 
>>> 
>>> 
>>> thanks
>>> Venkat 
>>> 
>>> 
 On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko  
 wrote:
 Hi Venkat,
 
 Before doing ACL checks, acl-plugin checks the establshed sessions on
 the given interface.
 
 If an already established session is hit the action is set to "3" and
 no further ACL check is done, which is what you see in your output.
 
 For that case, the ACL# in the trace is a special-case "-1", same as
 lc_index-1 - because we actually never get it to ACL lookup so do not
 need it; and the rule# is the session index; and the trace_bits tells
 us that this session is classifed to use timeout type "3", which is
 defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
 sense, since you are sending the packets in one direction and thus the
 session never establishes and the timeout type never changes to
 "TCP_IDLE".
 
 Of the packets you sent in total, 15002 packets  had hit the ACL#3
 rule and caused the sessions to be created. The rest of the packets
 had hit the established session entries and this is one of those that
 you have captured.
 
 At the time of taking the outputs the traffic was stopped and the
 sessions were deleted by idle timeout (which for the transient state
 is short).
 
 Does this make sense ?
 
 --a
 
 
 
 
 On 9/14/20, Venkat  wrote:
 > Hello Andrew,
 >
 > I am doing a simple test by sending TCP flows from Trex traffic 
 > generator.
 > Traffic source is 16.0.0.1-16.0.0.100 and destination is
 > 48.0.0.1-48.0.0.100.
 > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
 > Trex http profile.
 >
 > I have a reflective ACL to permit the flow for the above src and dst.
 > I expect the packet to hit acl index 3 rule 0 and get permitted.
 > However, I see the following match in the packet trace which doesn't seem
 > like it is hitting acl index 3 and rule 0 but hitting some other acl 
 > index
 > (acl -1 and lc_index -1).
 > What is the behavior here? Please provide some context here..
 >
 > 03:47:03:874624: acl-plugin-in-ip4-fa
 >
 > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3, match: 
 > acl
 > -1 rule 13309 trace_bits 80010303
 >
 > pkt info    
 > 43304310
 > 0001010600502d14 0310
 >
 > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1 proto 6
 > l4_is_input 1 l4_slow_path 0 

Re: [vpp-dev] Question about acl match/permit behavior.

[Venkat]

Thanks, Andrew,

And I noticed that sessions get deleted/reclaimed when ACL is disassociated
from the interface to which it was attached prior.
Maybe that's one option to have ACL detach and reattach to the interface
when there is any modification to the ACL to have immediately expected
behavior instead of waiting for the sessions to reclaim and reclassify.

thanks
Venkat

On Thu, Sep 17, 2020 at 10:39 AM Andrew  Yourtchenko 
wrote:

>
>
> On 17 Sep 2020, at 19:29, Venkat  wrote:
>
> 
> Andrew,
>
> I have a few follow up questions on the stated behavior.
>
> 1. Does the behavior you outlined about hitting special-case "-1" entries
> apply to UDP traffic as well if the ACL rule is stateful?
>
>
> Yup.
>
>
> 2. What happens when ACL config is modified while traffic is flowing?
> Would the packets continue to hit the special-case "-1" session until the
> session is timed out and re-claimed? If that's true, then packets would
> continue to sneak through even when a user modifies the ACL from
> Permit+Reflect to Deny.
>
>
> Yep. You can look at the code, there is a debug CLI tweak to reclassify
> sessions, but I am not sure anyone actually uses it.
>
> There is no “always right” answer to this ~20 year old question.
>
> ACL plugin is very explicitly not a “fancy firewall”.
>
>
> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL
> hit would result in the creation of such a session and subsequent packets
> would by-pass ACL rules and continue to be served by special-case "-1".
>
>
> ...as your have observed it. The return packets on that interface matching
> the same five tuple, too.
>
> —a
>
>
>
> thanks
> Venkat
>
>
> On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko 
> wrote:
>
>> Hi Venkat,
>>
>> Before doing ACL checks, acl-plugin checks the establshed sessions on
>> the given interface.
>>
>> If an already established session is hit the action is set to "3" and
>> no further ACL check is done, which is what you see in your output.
>>
>> For that case, the ACL# in the trace is a special-case "-1", same as
>> lc_index-1 - because we actually never get it to ACL lookup so do not
>> need it; and the rule# is the session index; and the trace_bits tells
>> us that this session is classifed to use timeout type "3", which is
>> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
>> sense, since you are sending the packets in one direction and thus the
>> session never establishes and the timeout type never changes to
>> "TCP_IDLE".
>>
>> Of the packets you sent in total, 15002 packets  had hit the ACL#3
>> rule and caused the sessions to be created. The rest of the packets
>> had hit the established session entries and this is one of those that
>> you have captured.
>>
>> At the time of taking the outputs the traffic was stopped and the
>> sessions were deleted by idle timeout (which for the transient state
>> is short).
>>
>> Does this make sense ?
>>
>> --a
>>
>>
>>
>>
>> On 9/14/20, Venkat  wrote:
>> > Hello Andrew,
>> >
>> > I am doing a simple test by sending TCP flows from Trex traffic
>> generator.
>> > Traffic source is 16.0.0.1-16.0.0.100 and destination is
>> > 48.0.0.1-48.0.0.100.
>> > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
>> > Trex http profile.
>> >
>> > I have a reflective ACL to permit the flow for the above src and dst.
>> > I expect the packet to hit acl index 3 rule 0 and get permitted.
>> > However, I see the following match in the packet trace which doesn't
>> seem
>> > like it is hitting acl index 3 and rule 0 but hitting some other acl
>> index
>> > (acl -1 and lc_index -1).
>> > What is the behavior here? Please provide some context here..
>> >
>> > 03:47:03:874624: acl-plugin-in-ip4-fa
>> >
>> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3,
>> match: acl
>> > -1 rule 13309 trace_bits 80010303
>> >
>> > pkt info   
>> 43304310
>> > 0001010600502d14 0310
>> >
>> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1 proto 6
>> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
>> > (valid) 10 rsvd 0
>> >
>> > DBGvpp# show acl-plugin acl
>> >
>> > acl-index 0 count 2 tag
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 0 dport 0
>> >
>> > 1: ipv6 deny src ::/0 dst ::/0 proto 0 sport 0 dport 0
>> >
>> > applied inbound on sw_if_index: 1
>> >
>> > applied outbound on sw_if_index:
>> >
>> > used in lookup context index: 1
>> >
>> > acl-index 1 count 6 tag
>> > {9-sra-inbound-sasefwpro-sase-default-fw-profile}
>> >
>> > 0: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport
>> 0-65535
>> > dport 0-65535
>> >
>> > 1: ipv6 permit+reflect src ::/0 dst ::/0 proto 6 sport 0-65535 dport
>> > 0-65535
>> >
>> > 2: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport
>> 0-65535
>> > dport 0-65535
>> >
>> > 3: 

Re: [vpp-dev] Question about acl match/permit behavior.

[Andrew Yourtchenko]

> On 17 Sep 2020, at 23:55, Venkat  wrote:
> 
> 
> 
>> 2. What happens when ACL config is modified while traffic is flowing? Would 
>> the packets continue to hit the special-case "-1" session until the session 
>> is timed out and re-claimed? If that's true, then packets would continue to 
>> sneak through even when a user modifies the ACL from Permit+Reflect to Deny. 
> 
> Yep. You can look at the code, there is a debug CLI tweak to reclassify 
> sessions, but I am not sure anyone actually uses it.
> 
> There is no “always right” answer to this ~20 year old question.
> 
> ACL plugin is very explicitly not a “fancy firewall”.
> 
> [VD]: One more question on this behavior. If packets continue to hit the 
> special-case "-1" session, would they ever hit the modified ACL? Or does the 
> reclassify sessions logic kick in periodically (every timeout independent of 
> traffic hit) and cleans up the special-case "-1" sessions so that new 
> sessions build up again based on the current state of ACLs rule? I would 
> assume, it's the latter case, otherwise, modified ACL would never hit if 
> traffic continues to flow.  

Only with the idle timeout.

ACL plugin is not intended to participate in a SWAT team, really. :-)

—a

> 
> 
>> On Thu, Sep 17, 2020 at 10:39 AM Andrew  Yourtchenko  
>> wrote:
>> 
>> 
 On 17 Sep 2020, at 19:29, Venkat  wrote:
 
>>> 
>>> Andrew,
>>> 
>>> I have a few follow up questions on the stated behavior. 
>>> 
>>> 1. Does the behavior you outlined about hitting special-case "-1" entries 
>>> apply to UDP traffic as well if the ACL rule is stateful? 
>> 
>> Yup.
>> 
>>> 
>>> 2. What happens when ACL config is modified while traffic is flowing? Would 
>>> the packets continue to hit the special-case "-1" session until the session 
>>> is timed out and re-claimed? If that's true, then packets would continue to 
>>> sneak through even when a user modifies the ACL from Permit+Reflect to 
>>> Deny. 
>> 
>> Yep. You can look at the code, there is a debug CLI tweak to reclassify 
>> sessions, but I am not sure anyone actually uses it.
>> 
>> There is no “always right” answer to this ~20 year old question.
>> 
>> ACL plugin is very explicitly not a “fancy firewall”.
>> 
>>> 
>>> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL hit 
>>> would result in the creation of such a session and subsequent packets would 
>>> by-pass ACL rules and continue to be served by special-case "-1". 
>> 
>> ...as your have observed it. The return packets on that interface matching 
>> the same five tuple, too.
>> 
>> —a
>> 
>>> 
>>> 
>>> thanks
>>> Venkat 
>>> 
>>> 
 On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko  
 wrote:
 Hi Venkat,
 
 Before doing ACL checks, acl-plugin checks the establshed sessions on
 the given interface.
 
 If an already established session is hit the action is set to "3" and
 no further ACL check is done, which is what you see in your output.
 
 For that case, the ACL# in the trace is a special-case "-1", same as
 lc_index-1 - because we actually never get it to ACL lookup so do not
 need it; and the rule# is the session index; and the trace_bits tells
 us that this session is classifed to use timeout type "3", which is
 defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
 sense, since you are sending the packets in one direction and thus the
 session never establishes and the timeout type never changes to
 "TCP_IDLE".
 
 Of the packets you sent in total, 15002 packets  had hit the ACL#3
 rule and caused the sessions to be created. The rest of the packets
 had hit the established session entries and this is one of those that
 you have captured.
 
 At the time of taking the outputs the traffic was stopped and the
 sessions were deleted by idle timeout (which for the transient state
 is short).
 
 Does this make sense ?
 
 --a
 
 
 
 
 On 9/14/20, Venkat  wrote:
 > Hello Andrew,
 >
 > I am doing a simple test by sending TCP flows from Trex traffic 
 > generator.
 > Traffic source is 16.0.0.1-16.0.0.100 and destination is
 > 48.0.0.1-48.0.0.100.
 > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
 > Trex http profile.
 >
 > I have a reflective ACL to permit the flow for the above src and dst.
 > I expect the packet to hit acl index 3 rule 0 and get permitted.
 > However, I see the following match in the packet trace which doesn't seem
 > like it is hitting acl index 3 and rule 0 but hitting some other acl 
 > index
 > (acl -1 and lc_index -1).
 > What is the behavior here? Please provide some context here..
 >
 > 03:47:03:874624: acl-plugin-in-ip4-fa
 >
 > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3, match: 
 > acl
 > -1 rule 13309 trace_bits 80010303
 >
 > 

Re: [vpp-dev] Question about acl match/permit behavior.

[Venkat]

2. What happens when ACL config is modified while traffic is flowing? Would
the packets continue to hit the special-case "-1" session until the session
is timed out and re-claimed? If that's true, then packets would continue to
sneak through even when a user modifies the ACL from Permit+Reflect to
Deny.


Yep. You can look at the code, there is a debug CLI tweak to reclassify
sessions, but I am not sure anyone actually uses it.

There is no “always right” answer to this ~20 year old question.

ACL plugin is very explicitly not a “fancy firewall”.

[VD]: One more question on this behavior. If packets continue to hit
the special-case "-1" session, would they ever hit the modified ACL? Or
does the reclassify sessions logic kick in periodically (every timeout
independent of traffic hit) and cleans up the special-case "-1" sessions so
that new sessions build up again based on the current state of ACLs rule? I
would assume, it's the latter case, otherwise, modified ACL would never hit
if traffic continues to flow.


On Thu, Sep 17, 2020 at 10:39 AM Andrew  Yourtchenko 
wrote:

>
>
> On 17 Sep 2020, at 19:29, Venkat  wrote:
>
> 
> Andrew,
>
> I have a few follow up questions on the stated behavior.
>
> 1. Does the behavior you outlined about hitting special-case "-1" entries
> apply to UDP traffic as well if the ACL rule is stateful?
>
>
> Yup.
>
>
> 2. What happens when ACL config is modified while traffic is flowing?
> Would the packets continue to hit the special-case "-1" session until the
> session is timed out and re-claimed? If that's true, then packets would
> continue to sneak through even when a user modifies the ACL from
> Permit+Reflect to Deny.
>
>
> Yep. You can look at the code, there is a debug CLI tweak to reclassify
> sessions, but I am not sure anyone actually uses it.
>
> There is no “always right” answer to this ~20 year old question.
>
> ACL plugin is very explicitly not a “fancy firewall”.
>
>
> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL
> hit would result in the creation of such a session and subsequent packets
> would by-pass ACL rules and continue to be served by special-case "-1".
>
>
> ...as your have observed it. The return packets on that interface matching
> the same five tuple, too.
>
> —a
>
>
>
> thanks
> Venkat
>
>
> On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko 
> wrote:
>
>> Hi Venkat,
>>
>> Before doing ACL checks, acl-plugin checks the establshed sessions on
>> the given interface.
>>
>> If an already established session is hit the action is set to "3" and
>> no further ACL check is done, which is what you see in your output.
>>
>> For that case, the ACL# in the trace is a special-case "-1", same as
>> lc_index-1 - because we actually never get it to ACL lookup so do not
>> need it; and the rule# is the session index; and the trace_bits tells
>> us that this session is classifed to use timeout type "3", which is
>> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
>> sense, since you are sending the packets in one direction and thus the
>> session never establishes and the timeout type never changes to
>> "TCP_IDLE".
>>
>> Of the packets you sent in total, 15002 packets  had hit the ACL#3
>> rule and caused the sessions to be created. The rest of the packets
>> had hit the established session entries and this is one of those that
>> you have captured.
>>
>> At the time of taking the outputs the traffic was stopped and the
>> sessions were deleted by idle timeout (which for the transient state
>> is short).
>>
>> Does this make sense ?
>>
>> --a
>>
>>
>>
>>
>> On 9/14/20, Venkat  wrote:
>> > Hello Andrew,
>> >
>> > I am doing a simple test by sending TCP flows from Trex traffic
>> generator.
>> > Traffic source is 16.0.0.1-16.0.0.100 and destination is
>> > 48.0.0.1-48.0.0.100.
>> > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
>> > Trex http profile.
>> >
>> > I have a reflective ACL to permit the flow for the above src and dst.
>> > I expect the packet to hit acl index 3 rule 0 and get permitted.
>> > However, I see the following match in the packet trace which doesn't
>> seem
>> > like it is hitting acl index 3 and rule 0 but hitting some other acl
>> index
>> > (acl -1 and lc_index -1).
>> > What is the behavior here? Please provide some context here..
>> >
>> > 03:47:03:874624: acl-plugin-in-ip4-fa
>> >
>> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3,
>> match: acl
>> > -1 rule 13309 trace_bits 80010303
>> >
>> > pkt info   
>> 43304310
>> > 0001010600502d14 0310
>> >
>> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1 proto 6
>> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
>> > (valid) 10 rsvd 0
>> >
>> > DBGvpp# show acl-plugin acl
>> >
>> > acl-index 0 count 2 tag
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 0: ipv4 deny src 

Re: [vpp-dev] run existing plugin in VPP

[hemant via lists.fd.io]

I haven’t planned auto-generation of test_xxx.py yet.

 

Looking at test_cdp.py, I see lot of python code which should be common to most 
plugin PTF tests.  Thereafter, creating a good and bad packet for a protocol., 
enabling/disabling plugin should be straightforward to auto-generate.  I think, 
I can generate tests_xxx.py and thereafter if a user wants, more tests or 
tweaks could be added. 

 

Hemant

 

From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Thursday, September 17, 2020 2:21 AM
To: hem...@mnkcg.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] run existing plugin in VPP

 

Excellent!

 

So would my guess be right that you plan to autogenerate the tests as well ?

--a





On 17 Sep 2020, at 02:54, hem...@mnkcg.com   wrote:



I did a “ps -ef | grep -I vpp” and found a few vpp processes (?) running.  I 
killed them and then the single cdp test ran fine on using “sudo make test 
TEST=test_cdp” from vpp root directory.  

 

==

CDP Test Case 

==

test_cdp_overflow_tlv (test_cdp.TestCDP) 0.28 OK

test_cdp_underflow_tlv (test_cdp.TestCDP)0.29 OK

test_enable_cdp (test_cdp.TestCDP)   0.23 OK

test_send_cdp_packet (test_cdp.TestCDP)  0.28 OK

 

==

TEST RESULTS:

 Scheduled tests: 4

  Executed tests: 4

Passed tests: 4

==

 

Hemant

 

From: hem...@mnkcg.com   mailto:hem...@mnkcg.com> > 
Sent: Wednesday, September 16, 2020 7:43 PM
To: 'ayour...@gmail.com' mailto:ayour...@gmail.com> >
Cc: 'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io> >
Subject: RE: [vpp-dev] run existing plugin in VPP

 

Andrew,

 

Thanks.  I will have to play more with VPP because “sudo make test 
TEST=test_cdp” fails.  If anyone else is able to run this test, then I know I 
have some issues with my VPP setup or dependencies.

 

I found the CSIT reports – thanks!

 

Regarding my p4 to vpp compiler, it’s work in progress.  I will update you all 
when something is ready for use.

 

Hemant  

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Andrew Yourtchenko
Sent: Wednesday, September 16, 2020 7:10 PM
To: hem...@mnkcg.com  
Cc: vpp-dev@lists.fd.io  
Subject: Re: [vpp-dev] run existing plugin in VPP

 

Hemant,

 

On 17 Sep 2020, at 00:43, hem...@mnkcg.com   wrote:



Andrew,

 

Thanks!  Yes, I am a developer trying to get started with VPP.  

 

 

Cool! So my “find the answer” quiz was on target :-)

 

I run VPP using “make run-release” and get to the “vpp#” prompt.  I could do a 
“cdp enable” and thus I know this plugin has been loaded.  

 

Now how to I run the packet testing in vpp/src/plugins/cdp/test/?  There is a 
test_cdp.py in the path.  I am familiar with PTF.

 

“Make test-help” will give more info.

 

Once I can run test.py for a plugin, I’d like to learn how to run performance 
testing to see how many packets/sec of a certain size I can achieve for a 
plugin.  What would be a good plugin to test performance with?

 

That’s trickier... look around  https://wiki.fd.io/view/CSIT - basically, perf 
testing the VPP is a separate project :-) but the good thing is some reports 
might be already there..

 

 

I love the fact that you (and perhaps others) have added lua examples to 
vpp-api.

 

Lua didn’t get much love for quite a while and I think would need some 
resuscitations to work :-)

That said, last time I had a half a day to toy  with it, in half a day I had 
something sorta working... but don’t expect what is in the tree to be up to 
date... it’s waiting for the folks to help it :-)

 

 

I am developing a compiler which ingests P4 code and outputs a VPP plugin.  
First, I will make the compiler functionally correct to support as many P4 
features and as many VPP features.  Then I will worry about performance which 
is a hard problem.

 

This is a fun idea!

 

 

If you see a VPP plugin, several files can be auto-generated by compiler or 
script.  My compiler is already generating these files:

 

-rw-rw-r--  1 hemant hemant   1498 Sep 16 18:38 tmp_test.c

-rw-rw-r--  1 hemant hemant  10577 Sep 16 18:38 tmp.h

-rw-rw-r--  1 hemant hemant  79257 Sep 16 18:38 tmp.c

-rw-rw-r--  1 hemant hemant412 Sep 16 18:38 tmp.api

-rw-rw-r--  1 hemant hemant250 Sep 16 18:38 CMakeLists.txt

 

Nice! There is the lisp script somewhere in the tree that asks questions and 
spits out the plugin, but it’s a skeleton, with P4 one could probably go quite 
a good bit further...

 

Re: [vpp-dev] Unable to compile vpp under ubuntu 18.04

[Benoit Ganne (bganne) via lists.fd.io]

> I'm trying to build from source vpp (v18.04) on ubuntu 18.04, but still no
> luck. Compilation throws errors. I've got the same error with vpp v18.10
> too
> Could anybody help me with compilation ?

I bet you are missing build dependencies, see 
https://fd.io/vppproject/vppbuilding/
In short, You must run 'make install-dep' to install those.
Then, you can install VPP external dependencies with 'make install-ext-dep'. It 
would prevent you to rebuild dpdk, etc. each time and will speed up rebuilds.

Best
ben

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17445): https://lists.fd.io/g/vpp-dev/message/17445
Mute This Topic: https://lists.fd.io/mt/76911197/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] Happy Trails to Me...

[St Leger, Jim]

Dave:

Wow...I'm starting to wonder what the community would do without you, but 
grateful to hear you'll remain active.

You have been "the" foundation of FD.io wrt VPP since the inception (and of 
course for many more years when VPP was solely software within Cisco.)

Your leadership and contributions have been invaluable. We are all tremendously 
indebted and grateful for all that you've done. And we will continue to be 
appreciative for all you will continue to do.

All the very best,
Jim


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of d...@barachs.net
Sent: Thursday, September 17, 2020 7:32 AM
To: vpp-dev@lists.fd.io; t...@lists.fd.io
Subject: [vpp-dev] Happy Trails to Me...

Folks,

I'm departing the employment rolls towards the end of next month. Although I 
intend to remain active in the fd.io vpp community as a coder, committer, and 
resident greybeard, it's time for the community to pick a new PTL. 

According to the project governance document,
https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:  

3.2.3.1 Project Technical Leader Candidates Candidates for the project's PTL 
will be derived from the Committers of the Project. Candidates must 
self-nominate.

I'd like to invite any interested vpp project committer to self-nominate for 
the PTL role. Please email vpp-dev@lists.fd.io.

Let's close the self-nomination period in one week: more specifically, by 5pm 
EDT on Thursday, September 24, 2020; committer vote to follow thereafter.

I'll be glad to answer unicast questions about the PTL role from eligible 
committers.

Thanks... Dave  







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17446): https://lists.fd.io/g/vpp-dev/message/17446
Mute This Topic: https://lists.fd.io/mt/76911198/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] [tsc] Happy Trails to Me...

[Damjan Marion via lists.fd.io]

Dear Dave,

It is not surprise to me as we already spoke about this several times.
I’m glad that you decided to stay with us and help this project grow, even
after you step down from the PTL role.

As you said, we need to elect new PTL, and I would like to nominate myself.

If I am elected, I know it will not be easy to fill your shoes and I will
count on your help to get me running.

Thank you for driving this project as PTL since day 1, back in 2015.
I’m looking forward to continue to work closely with you and continue to
do cool staff.


Best,

Damjan



> On 17 Sep 2020, at 16:31, d...@barachs.net wrote:
> 
> Folks,
> 
> I'm departing the employment rolls towards the end of next month. Although I
> intend to remain active in the fd.io vpp community as a coder, committer,
> and resident greybeard, it's time for the community to pick a new PTL. 
> 
> According to the project governance document,
> https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:  
> 
> 3.2.3.1 Project Technical Leader Candidates 
> Candidates for the project's PTL will be derived from the Committers of the
> Project. Candidates must self-nominate.
> 
> I'd like to invite any interested vpp project committer to self-nominate for
> the PTL role. Please email vpp-dev@lists.fd.io.
> 
> Let's close the self-nomination period in one week: more specifically, by
> 5pm EDT on Thursday, September 24, 2020; committer vote to follow
> thereafter.
> 
> I'll be glad to answer unicast questions about the PTL role from eligible
> committers.
> 
> Thanks... Dave  
> 
> 
> 
> 
> 
> 
> 
> 
> 


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

[vpp-dev] Happy Trails to Me...

[dave]

Folks,

I’m departing the employment rolls towards the end of next month. Although I
intend to remain active in the fd.io vpp community as a coder, committer,
and resident greybeard, it’s time for the community to pick a new PTL. 

According to the project governance document,
https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:  

3.2.3.1 Project Technical Leader Candidates 
Candidates for the project’s PTL will be derived from the Committers of the
Project. Candidates must self-nominate.

I'd like to invite any interested vpp project committer to self-nominate for
the PTL role. Please email vpp-dev@lists.fd.io.

Let's close the self-nomination period in one week: more specifically, by
5pm EDT on Thursday, September 24, 2020; committer vote to follow
thereafter.

I'll be glad to answer unicast questions about the PTL role from eligible
committers.

Thanks... Dave  







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17442): https://lists.fd.io/g/vpp-dev/message/17442
Mute This Topic: https://lists.fd.io/mt/76911198/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] ping not able to receive replies on vpp interface

[Pac Ette]

Hi Filip,

Sounds good.

Thanks!

On Thu, Sep 17, 2020 at 1:27 AM Filip Varga -X (fivarga - PANTHEON TECH SRO
at Cisco)  wrote:

> Hi Pac,
>
>
>
> Yes the idea is that you should be able to ping NAT outside interface from
> the adjacent side of the connection. This was previously working. I will
> create a ticket for the issue and look in to it shortly.
>
>
>
> If you have any other issues with NAT please let me know.
>
>
>
> Best regards,
> Filip
>
>
>
> *From:* Pac Ette 
> *Sent:* Wednesday, September 16, 2020 10:16 PM
> *To:* pktno...@gmail.com
> *Cc:* Filip Varga -X (fivarga - PANTHEON TECH SRO at Cisco) <
> fiva...@cisco.com>; Dave Barach (dbarach) ;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] ping not able to receive replies on vpp interface
> *Importance:* High
>
>
>
> Hi Filip,
>
>
>
> sorry, amendment to my last email:
>
>
>
> Your suggestion worked. But ping from linux stack (tap interface) is not
> working because there is no NAT in/out anymore.
>
>
>
> I am using VPP with NAT. Is it not possible for ping to work with NAT?
>
>
>
> I noticed something. If I add back:
>
>
>
> set interface nat44 in loop0 in loop1
> set interface nat44 out wan1
>
>
>
> In addition to vpp-to-server not working, I am also unable to ping from
> linux server to vpp box.
>
>
>
> $ ping 10.200.1.7
> PING 10.200.1.7 (10.200.1.7) from 10.200.1.1 eth2: 56(84) bytes of data.
> --- 10.200.1.7 ping statistics ---
> 80 packets transmitted, 0 received, 100% packet loss, time 80882ms
>
>
>
> Thanks!
>
>
>
> On Wed, Sep 16, 2020 at 1:10 PM Pac Ette via lists.fd.io  gmail@lists.fd.io> wrote:
>
> Hi Filip,
>
>
>
> Your suggestion worked. But I am using VPP with NAT. Is it not possible
> for ping to work with NAT?
>
>
>
> I noticed something. When NAT is set, in addition to vpp to server not
> working, I am also unable to ping from linux server to vpp box.
>
>
>
> If I add back:
>
> set interface nat44 in loop0 in loop1
> set interface nat44 out wan1
>
>
>
> linux (10.200.1.1) --> to --> wan1 (vpp) does not work either.
>
>
>
> Thanks!
>
>
>
>
>
> On Wed, Sep 16, 2020 at 12:35 PM Filip Varga -X (fivarga - PANTHEON TECH
> SRO at Cisco)  wrote:
>
> Hi Pac,
>
>
>
> Try removing from your configuration following two lines:
>
>
>
> set interface nat44 in loop0 in loop1
> set interface nat44 out wan1
>
>
>
> Now try to ping from linux & vpp. From linux ping vpp wan interface
> 10.200.1.7 and from vpp linux host 10.200.1.1 (don’t forget to specify the
> source interface, this should be your wan interface in vpp).
>
>
>
> # ping  source 
>
>
>
> Best regards,
>
> Filip
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Pac Ette
> *Sent:* Wednesday, September 16, 2020 6:14 PM
> *To:* Dave Barach (dbarach) 
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] ping not able to receive replies on vpp interface
>
>
>
> Hi Dave,
>
>
>
> I had a suspicion that my configs might be wrong. But, why would packets
> go through the NAT plugin when I am pinging from vppctl and directly on the
> wan1 port - I was thinking these packets don't need to be NAT-ed. Here are
> my configs and testing results.
>
>
>
> ## Configs
> cat vpp.conf
> set interface state wan1 up
> set interface state lan3 up
> set interface state lan2 up
> set interface state lan0 up
>
> set dhcp client intfc wan1 hostname test-ccB
>
> loopback create
> set interface l2 bridge loop0 1 bvi
> set interface ip address loop0 10.90.0.1/16
> set interface state loop0 up
>
> create tap id 0 host-ip4-addr 10.90.0.2/16 host-if-name lstack1
> set interface l2 bridge tap0 1
> set interface state tap0 up
>
> loopback create
> set interface l2 bridge loop1 2 bvi
> set interface ip address loop1 10.100.0.1/16
> set interface state loop1 up
>
> set interface l2 bridge lan0 2
> set interface l2 bridge lan2 2
> set interface l2 bridge lan3 2
>
> create tap id 1 host-ip4-addr 10.100.0.2/16 host-if-name lstack2
> set interface l2 bridge tap1 2
> set interface state tap1 up
>
> nat44 add interface address wan1
> set interface nat44 in loop0 in loop1
> set interface nat44 out wan1
> --
> vpp# sh nat44 addresses
> NAT44 pool addresses:
> 10.200.1.7
>   tenant VRF independent
>   0 busy other ports
>   18 busy udp ports
>   0 busy tcp ports
>   0 busy icmp ports
> NAT44 twice-nat pool addresses:
>
> vpp# sh nat44 interfaces
> NAT44 interfaces:
>  loop0 in
>  loop1 in
>  wan1 out
>
> vpp# sh dhcp client
> [0] wan1 state DHCP_BOUND installed 1 addr 10.200.1.7/24 gw 10.200.1.1
> server 10.200.1.1 dns 8.8.8.8
>
> linux stack
> $ ip route
> default via 10.90.0.1 dev  lstack1
> 10.90.0.0/16 dev lstack1 proto kernel scope link src 10.90.0.2
> 10.100.0.0/16 dev lstack2 proto kernel scope link src 10.100.0.2
> --
> ## Testing
>
> pings via linux stack works but pings via vppctl do not.
>
> ping via vppctl:
> vpp# ping 10.200.1.1
> Statistics: 5 sent, 0 received, 100% packet loss
>
> ping via 

Re: [vpp-dev] run existing plugin in VPP

[Andrew Yourtchenko]

> On 17 Sep 2020, at 14:59, hem...@mnkcg.com wrote:
> 
> 
> I haven’t planned auto-generation of test_xxx.py yet.
>  
> Looking at test_cdp.py, I see lot of python code which should be common to 
> most plugin PTF tests.  Thereafter, creating a good and bad packet for a 
> protocol., enabling/disabling plugin should be straightforward to 
> auto-generate.  I think, I can generate tests_xxx.py and thereafter if a user 
> wants, more tests or tweaks could be added.

Yup, that would be very cool, because assuming the initial definition is 
correct and complete, then generating positive/negative tests should be 
possible mechanically. Since you know what at least the initial code structure 
is, you could make tests that hit every basic block at least in the initial 
code; and then some potentially based on the derived ranges of allowable 
values... (eg, if a feature is unicast, try feeding broadcast and see what 
happens, etc). If there are way too many tests then they can be moved to 
extended tests...

Then one can more comfortably tweak the subsequent implementation of the node 
by hand to get more performance...

Just one catch with the building the tests: there are three “timelines” in any 
of them:
- time as seen by the python executor
- time as seen by the VPP instance being driven
- time as seen by the external observer

At high concurrency they may become different things, so that might trip up the 
tests that assume they are all the same... 

—a


>  
> Hemant
>  
> From: vpp-dev@lists.fd.io  On Behalf Of Andrew 
> Yourtchenko
> Sent: Thursday, September 17, 2020 2:21 AM
> To: hem...@mnkcg.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] run existing plugin in VPP
>  
> Excellent!
>  
> So would my guess be right that you plan to autogenerate the tests as well ?
> 
> --a
> 
> 
> On 17 Sep 2020, at 02:54, hem...@mnkcg.com wrote:
> 
> 
> I did a “ps -ef | grep -I vpp” and found a few vpp processes (?) running.  I 
> killed them and then the single cdp test ran fine on using “sudo make test 
> TEST=test_cdp” from vpp root directory. 
>  
> ==
> CDP Test Case
> ==
> test_cdp_overflow_tlv (test_cdp.TestCDP) 0.28 OK
> test_cdp_underflow_tlv (test_cdp.TestCDP)0.29 OK
> test_enable_cdp (test_cdp.TestCDP)   0.23 OK
> test_send_cdp_packet (test_cdp.TestCDP)  0.28 OK
>  
> ==
> TEST RESULTS:
>  Scheduled tests: 4
>   Executed tests: 4
> Passed tests: 4
> ==
>  
> Hemant
>  
> From: hem...@mnkcg.com  
> Sent: Wednesday, September 16, 2020 7:43 PM
> To: 'ayour...@gmail.com' 
> Cc: 'vpp-dev@lists.fd.io' 
> Subject: RE: [vpp-dev] run existing plugin in VPP
>  
> Andrew,
>  
> Thanks.  I will have to play more with VPP because “sudo make test 
> TEST=test_cdp” fails.  If anyone else is able to run this test, then I know I 
> have some issues with my VPP setup or dependencies.
>  
> I found the CSIT reports – thanks!
>  
> Regarding my p4 to vpp compiler, it’s work in progress.  I will update you 
> all when something is ready for use.
>  
> Hemant 
>  
> From: vpp-dev@lists.fd.io  On Behalf Of Andrew 
> Yourtchenko
> Sent: Wednesday, September 16, 2020 7:10 PM
> To: hem...@mnkcg.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] run existing plugin in VPP
>  
> Hemant,
>  
> 
> On 17 Sep 2020, at 00:43, hem...@mnkcg.com wrote:
> 
> 
> Andrew,
>  
> Thanks!  Yes, I am a developer trying to get started with VPP. 
>  
>  
> Cool! So my “find the answer” quiz was on target :-)
>  
> 
> I run VPP using “make run-release” and get to the “vpp#” prompt.  I could do 
> a “cdp enable” and thus I know this plugin has been loaded. 
>  
> Now how to I run the packet testing in vpp/src/plugins/cdp/test/?  There is a 
> test_cdp.py in the path.  I am familiar with PTF.
>  
> “Make test-help” will give more info.
>  
> 
> Once I can run test.py for a plugin, I’d like to learn how to run performance 
> testing to see how many packets/sec of a certain size I can achieve for a 
> plugin.  What would be a good plugin to test performance with?
>  
> That’s trickier... look around  https://wiki.fd.io/view/CSIT - basically, 
> perf testing the VPP is a separate project :-) but the good thing is some 
> reports might be already there..
>  
>  
> I love the fact that you (and perhaps others) have added lua examples to 
> vpp-api.
>  
> Lua didn’t get much love for quite a while and I think would need some 
> resuscitations to work :-)
> That said, last time I had a half a day to toy  with it, in half a day I had 
> something sorta working... but don’t expect what is in the tree to be up to 
> 

Re: [vpp-dev] Question about acl match/permit behavior.

[Venkat]

Andrew,

I have a few follow up questions on the stated behavior.

1. Does the behavior you outlined about hitting special-case "-1" entries
apply to UDP traffic as well if the ACL rule is stateful?

2. What happens when ACL config is modified while traffic is flowing? Would
the packets continue to hit the special-case "-1" session until the session
is timed out and re-claimed? If that's true, then packets would continue to
sneak through even when a user modifies the ACL from Permit+Reflect to
Deny.

3. And regarding the special-case "-1" lookups, I assume a stateful ACL hit
would result in the creation of such a session and subsequent packets would
by-pass ACL rules and continue to be served by special-case "-1".


thanks
Venkat


On Tue, Sep 15, 2020 at 2:01 AM Andrew  Yourtchenko 
wrote:

> Hi Venkat,
>
> Before doing ACL checks, acl-plugin checks the establshed sessions on
> the given interface.
>
> If an already established session is hit the action is set to "3" and
> no further ACL check is done, which is what you see in your output.
>
> For that case, the ACL# in the trace is a special-case "-1", same as
> lc_index-1 - because we actually never get it to ACL lookup so do not
> need it; and the rule# is the session index; and the trace_bits tells
> us that this session is classifed to use timeout type "3", which is
> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
> sense, since you are sending the packets in one direction and thus the
> session never establishes and the timeout type never changes to
> "TCP_IDLE".
>
> Of the packets you sent in total, 15002 packets  had hit the ACL#3
> rule and caused the sessions to be created. The rest of the packets
> had hit the established session entries and this is one of those that
> you have captured.
>
> At the time of taking the outputs the traffic was stopped and the
> sessions were deleted by idle timeout (which for the transient state
> is short).
>
> Does this make sense ?
>
> --a
>
>
>
>
> On 9/14/20, Venkat  wrote:
> > Hello Andrew,
> >
> > I am doing a simple test by sending TCP flows from Trex traffic
> generator.
> > Traffic source is 16.0.0.1-16.0.0.100 and destination is
> > 48.0.0.1-48.0.0.100.
> > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers via
> > Trex http profile.
> >
> > I have a reflective ACL to permit the flow for the above src and dst.
> > I expect the packet to hit acl index 3 rule 0 and get permitted.
> > However, I see the following match in the packet trace which doesn't seem
> > like it is hitting acl index 3 and rule 0 but hitting some other acl
> index
> > (acl -1 and lc_index -1).
> > What is the behavior here? Please provide some context here..
> >
> > 03:47:03:874624: acl-plugin-in-ip4-fa
> >
> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3, match:
> acl
> > -1 rule 13309 trace_bits 80010303
> >
> > pkt info   
> 43304310
> > 0001010600502d14 0310
> >
> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1 proto 6
> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
> > (valid) 10 rsvd 0
> >
> > DBGvpp# show acl-plugin acl
> >
> > acl-index 0 count 2 tag
> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
> >
> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 0 dport 0
> >
> > 1: ipv6 deny src ::/0 dst ::/0 proto 0 sport 0 dport 0
> >
> > applied inbound on sw_if_index: 1
> >
> > applied outbound on sw_if_index:
> >
> > used in lookup context index: 1
> >
> > acl-index 1 count 6 tag
> > {9-sra-inbound-sasefwpro-sase-default-fw-profile}
> >
> > 0: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport 0-65535
> > dport 0-65535
> >
> > 1: ipv6 permit+reflect src ::/0 dst ::/0 proto 6 sport 0-65535 dport
> > 0-65535
> >
> > 2: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport
> 0-65535
> > dport 0-65535
> >
> > 3: ipv6 permit+reflect src ::/0 dst ::/0 proto 17 sport 0-65535 dport
> > 0-65535
> >
> > 4: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535
> > dport 0-65535
> >
> > 5: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535
> > dport 0-65535
> >
> > applied inbound on sw_if_index: 1
> >
> > applied outbound on sw_if_index:
> >
> > used in lookup context index: 1
> >
> > acl-index 2 count 6 tag
> > {9-sra-outbound-sasefwpro-sase-default-fw-profile}
> >
> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport 0-65535 dport
> > 0-65535
> >
> > 1: ipv6 deny src ::/0 dst ::/0 proto 6 sport 0-65535 dport 0-65535
> >
> > 2: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport 0-65535 dport
> > 0-65535
> >
> > 3: ipv6 deny src ::/0 dst ::/0 proto 17 sport 0-65535 dport 0-65535
> >
> > 4: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535 dport
> > 0-65535
> >
> > 5: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535 dport
> > 0-65535
> >
> > applied inbound on