date:20200811

Re: [vpp-dev] generic TCP MSS clamping

2020-08-11 Thread Ole Troan

Hi Miklos,

> do you see any remaining issue with the TCP MSS clamping plugin that has not 
> been addressed yet?
> The patch set has been hanging for quite some time and I am wondering how we 
> could proceed further. https://gerrit.fd.io/r/c/vpp/+/15144

Just did a code review. Please look.
If you take a look at them I will talk to Neale about removing his -2.

Best regards,
Ole

> 
> Thanks,
> Miklos
> From: vpp-dev@lists.fd.io  on behalf of Miklos Tirpak 
> via lists.fd.io
> Sent: Sunday, May 31, 2020 6:37 PM
> To: Paul Vinciguerra 
> Cc: otr...@employees.org ; Mohsin Kazmi (sykazmi) 
> ; vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Thanks lot, Paul. I have updated the patch set.
> 
> I would appreciate a second look at the checksum around tmc_node.c:124. The 
> function updates the TCP checksum instead of recalculating that now. I just 
> find the usage of ip_csum_update() a bit unclear, there are also comments 
> about cheating in other plugins.
> 
> Thanks,
> Miklos
> From: Paul Vinciguerra 
> Sent: Sunday, May 31, 2020 12:05 PM
> To: Miklós Tirpák 
> Cc: otr...@employees.org ; Mohsin Kazmi (sykazmi) 
> ; vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Yes, please do.  My changeset only freshens the api code to take advantage of 
> the refactorings that have been put in place since that code was last 
> submitted and fix the tests to work properly under python3 in anticipation of 
> your changes. 
> 
> Paul
> 
> On Sun, May 31, 2020 at 5:23 AM Miklós Tirpák  
> wrote:
> Hi Paul,
> 
> I just saw the updated patch from you in 
> https://gerrit.fd.io/r/c/vpp/+/15144/2.
> We discussed on the mailing list few days ago that I am working on updating 
> this plugin, and your patch is a bit conflicting with my changes 
> unfortunately.
> 
> If you do not mind I would still update the patch set in this code review 
> with some more changes: RX support, bugfix in clamping (mss is changed even 
> if it is low enough), some more tests, cli command updates. I hope I can do 
> this quickly.
> 
> Thanks,
> Miklos
> From: vpp-dev@lists.fd.io  on behalf of Miklos Tirpak 
> via lists.fd.io
> Sent: Thursday, May 28, 2020 4:51 PM
> To: otr...@employees.org ; Mohsin Kazmi (sykazmi) 
> 
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Thank you for the pointer, this is exactly what I was looking for. I will 
> rebase the patch and add RX support.
> 
> Thanks,
> Miklos
> From: otr...@employees.org 
> Sent: Thursday, May 28, 2020 12:43 PM
> To: Mohsin Kazmi (sykazmi) 
> Cc: Miklós Tirpák ; vpp-dev@lists.fd.io 
> 
> Subject: Re: [vpp-dev] generic TCP MSS clamping
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Good find Mohsin. So it's only missing clamping on RX. I'm sure Miklos can 
> add that.
> 
> Cheers,
> Ole
> 
> > On 28 May 2020, at 12:23, Mohsin Kazmi (sykazmi)  wrote:
> >
> > Hi Miklos,
> >
> > May be, it will help https://gerrit.fd.io/r/c/vpp/+/15144
> >
> > -br
> > Mohsin
> > From:  on behalf of Ole Troan 
> > Date: Thursday, May 28, 2020 at 11:23 AM
> > To: Miklos Tirpak 
> > Cc: "vpp-dev@lists.fd.io" 
> > Subject: Re: [vpp-dev] generic TCP MSS clamping
> >
> > Hi Miklos,
> >
> > > I see the NAT plugin already supports TCP MSS clamping but it is 
> > > implemented only in in2out direction.
> > >
> > > We have endpoints with wrong MTUs behind tunnels and not all the traffic 
> > > is NATed. Hence, it would be very nice to have generic support for MSS 
> > > clamping that could be enabled on the tunnel interface.
> > >
> > > Do you think implementing this as a feature arch would make sense? Then 
> > > it would not be limited to NAT or to one kind of tunnel for example.
> > > If so, what is the best place? A new plugin?
> >
> > A bidirectional TCP MSS adjust would be fine.
> > Putting it in a plugin is likely the simplest.
> >
> > I'm unsure if it should be generic or not. E.g. the NAT also needs to 
> > adjust the TCP checksum, and it's likely better to do it only once.
> >
> > Best regards,
> > Ole
> > 
> 
> 

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

View/Reply Online (#17184): https://lists.fd.io/g/vpp-dev/message/17184
Mute This Topic: https://lists.fd.io/mt/74499850/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://l

Re: [vpp-dev] Issue in VRRP functionality when compiling with devtoolset-7 with single worker configuration

2020-08-11 Thread Amit Mehra

Hi Matthews,

Thanks for the reply. I will try with this patch and will let you know my 
observations.

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

View/Reply Online (#17185): https://lists.fd.io/g/vpp-dev/message/17185
Mute This Topic: https://lists.fd.io/mt/76043759/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

2020-08-11 Thread Balaji Venkatraman via lists.fd.io

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

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 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
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 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

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

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
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 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 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

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

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
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 dst 
0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535

DBGvpp#


  *   Configure ABF Policy referring to the above created ACL


DBGvpp# abf policy add id 100 acl 1 via 10.39.27.227 wan


DBGvpp# show abf policy

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

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

  path:[47] pl-index:47 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,

10.39.27.227 wan

  [@0]: ipv4 via 10.39.27.227 wan: mtu:9000 b496915808e1b49691591f610800

DBGvpp# show abf attach lan

DBGvpp#


  *   Attach ABF Policy to the same interface as ACL Group 0 was attached. This 
will result in a vpp crash.


DBGvpp# abf attach ip4 policy 100 priority 100 lan



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


  *   Create another ACL for ABF configuration


vat# acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0


DBGvpp# show acl-plugin acl

acl-index 0 count 1 tag {}

  0: ipv4 permit src 11.11.11.0/24 dst 
0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535


  *   Configure

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

2020-08-11 Thread Neale Ranns via lists.fd.io


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

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 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
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 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

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

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
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 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 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

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

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
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 dst 
0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535

DBGvpp#


  *   Configure ABF Policy referring to the above created ACL


DBGvpp# abf policy add id 100 acl 1 via 10.39.27.227 wan


DBGvpp# show abf policy

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

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

  path:[47] pl-index:47 ip4 weight=1 pref=0 attached-nexthop:  
oper-flags:resolved,

10.39.27.227 wan

  [@0]: ipv4 via 10.39.27.227 wan: mtu:9000 b496915808e1b49691591f610800

DBGvpp# show abf attach lan

DBGvpp#


  *   Attach ABF Policy to the same interfac

Re: [vpp-dev] vpp19.08.2 crypto_ia32 do not support aes-gcm icv_size 8/12 crypto

2020-08-11 Thread Andrew Yourtchenko

We do have a batch of fixes scheduled for the final release of LTS 19.08.3, 
unfortunately this one didn’t get selected as it is a “refactor”. I tried to 
cherry-pick it, it depends on several patches, one of them renamed a plugin 
so that would be a no-go from the stability point of view.

With this in mind - 20.09 LTS is just around the corner, so I recommend to 
start adapting to it.

The current API deprecation process means you can start testing with the 
current master already, if you are not using any API marked as “deprecated” 
then you will be compatible with 20.09 LTS

--a

> On 10 Aug 2020, at 12:29, Damjan Marion via lists.fd.io 
>  wrote:
> 
>>> 1;
>>> }
>>> 
>>> 
>> 
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17188): https://lists.fd.io/g/vpp-dev/message/17188
Mute This Topic: https://lists.fd.io/mt/76100481/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

2020-08-11 Thread Andrew Yourtchenko



> On 11 Aug 2020, at 17:30, Neale Ranns (nranns)  wrote:
> 
> 
> 
> 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.

+1. Those two are orthogonal functions. ABF uses the acl as a service infra to 
select which traffic it deals with - but that’s it.

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

BTW - I did mark ABF APIs as “in-progress”, as we discussed a few months ago, 
so they are subject to changes. 

—a

> 
> 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
> 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 dst
> 40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect src
> 10.10.10.0/24, ipv4 permit+reflect src 
> 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
>   Name 
>Idx   Link  Hardware
> lan 
>1 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
> wan 
>2 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 dst 
> 40.40.40.1/32 proto 0 sport 1000 dport 1000
>   1:
>  ipv4 permit+reflect src 10.10.10.0/24 dst 
> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>   2:
>  ipv4 permit+reflect src 20.20.20.0/24 dst 
> 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 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 dst 
> 40.40.40.1/32 proto 0 sport 1000 dport 1000
>   1:
>  ipv4 permit+reflect src 10.10.10.0/24 dst 
> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>   2:
>  ipv4 permit+reflect src 20.20.20.0/24 dst 
> 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 dst 
> 0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535
> DBGvpp#
> 
> 
> Configure ABF Policy
>  referring to the above created ACL
> 
> 
> DBGvpp#
>  abf policy add id 100 acl 1 via 10.39.27.227 wan
> 
> DBGvpp#
>  show abf policy 
> abf:[0]:
>  policy:100 acl:1
>  path-list:[47]
>  locks:1 flags:shared,no-uRPF, uRPF-list: None
>   path:[47]
>  pl-index:47 ip4 weight=1 pref=0 attached-nexthop:

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

2020-08-11 Thread Venkat

Andres/Neale,

I confirm to see the same behavior when using ligato etcd proto models
which I believe eventually calls APIs in vpp.
Please let me know if you want me to do any further tests that would help
you fix the issues.

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.


+1. Those two are orthogonal functions. ABF uses the acl as a service infra
to select which traffic it deals with - but that’s it.


+1  [ VENKAT] I expected the same behavior but it doesn't look like it.

On Tue, Aug 11, 2020 at 9:33 AM Andrew 👽 Yourtchenko 
wrote:

>
>
> On 11 Aug 2020, at 17:30, Neale Ranns (nranns)  wrote:
>
> 
>
> 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.
>
>
> +1. Those two are orthogonal functions. ABF uses the acl as a service
> infra to select which traffic it deals with - but that’s it.
>
> Re the debug CLI, it's often not robust to garbage input. If the API has
> the same problem though, I'll fix it.
>
>
> BTW - I did mark ABF APIs as “in-progress”, as we discussed a few months
> ago, so they are subject to changes.
>
> —a
>
>
> 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 <
> ayour...@gmail.com>
> *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 
> --
> *From:* vpp-dev@lists.fd.io  on behalf of Venkat <
> venkat.dabb...@gmail.com>
> *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 dst 40.40.40.1/32
> sport 1000 dport 1000, ipv4 permit+reflect src 10.10.10.0/24, ipv4
> permit+reflect src 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 dst 40.40.40.1/32 proto 0
> sport 1000 dport 1000
>
>   1: ipv4 permit+reflect src 10.10.10.0/24 dst 0.0.0.0/0 proto 0
> sport 0-65535 dport 0-65535
>
>   2: ipv4 permit+reflect src 20.20.20.0/24 dst 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 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 dst 40.40.40.1/32 proto 0
> sport 1000 dport 1000
>
>   1: ipv4 permit+

[vpp-dev] Deterministic CGNAT vectors

2020-08-11 Thread Listas Tecnologia


Hi NAT VPP devs,


    First of all, thanks for your contribution to the community. We use 
Deterministic NAT feature on a huge demand, without any big problems.


    It´s about the harcoded limit of 1.000 sessions ( preallocated 
vectors) per host. I would like increase this value, it's safe to 
increase it to 4.000 sessions ?


    I'm aware of memory requirements to use this setting.

    Anyone had tried such setting ?


    Best regards,


--
Atenciosamente,

Paulo Salgado

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

View/Reply Online (#17191): https://lists.fd.io/g/vpp-dev/message/17191
Mute This Topic: https://lists.fd.io/mt/76135768/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

2020-08-11 Thread Venkat

Andrew/Neale,

We spent some more time today trying to root cause the issues. The
following are the VPP backtraces for the respective issues. We tried this
on VPP version 20.05
Hope this gives some clues towards fixing the issue.

Issue 1 Test Scenario:  ABF and ACL attached to the same interface

it is getting stuck at the spin_acquire_lock()



 Thread 1 (Thread 0x77fe0c40 (LWP 28339)):

 #0  0x743cff37 in sched_yield () at
../sysdeps/unix/syscall-template.S:78

 #1  0x751beb87 in spin_acquire_lock (sl=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:468

 #2  mspace_malloc (msp=0x7fffb42bc010, bytes=92) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4371

 #3  0x751beaa9 in mspace_get_aligned (msp=0x7fffb42bc010,
n_user_data_bytes=92, align=16,

 align_offset=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4254

 #4  0x7521cd57 in clib_mem_alloc_aligned_at_offset (size=72,
align=8, align_offset=8, os_out_of_memory_on_failure=1)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:142

 #5  vec_resize_allocate_memory (v=, length_increment=64,
data_bytes=72, header_bytes=,

 data_align=8, numa_id=255) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67

 #6  0x751fb670 in _vec_resize_inline (v=0x0,
length_increment=, data_bytes=,

 header_bytes=, data_align=,
numa_id=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170

 #7  serialize_vector_write (m=, s=0x7fffb5809980)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:903

 #8  0x751fb2b7 in serialize_write_not_inline (m=0x7fffb5809920,
s=0x7fffb5809980, n_bytes_to_write=4,

 flags=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:729

 #9  0x77bc77dc in serialize_stream_read_write
(header=0x7fffb5809920, s=, n_bytes=4, flags=2)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:140

 #10 serialize_get (m=0x7fffb5809920, n_bytes=4) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:180

 #11 serialize_integer (m=0x7fffb5809920, n_bytes=4, x=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:187

 #12 vl_api_serialize_message_table (am=0x77dd3c28 ,
vector=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:212

 #13 0x77bc7cb6 in vl_msg_api_trace_save (am=0x7fffb42bc010,
which=, fp=0x55986b80)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:261

 #14 0x77bc989d in vl_msg_api_post_mortem_dump ()

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:944

 #15 0xc756 in os_panic () at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:364

 #16 0x751c0afb in mspace_free (msp=0x7fffb42bc010, mem=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4548

 #17 0x7521cf0b in clib_mem_free (p=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:224

 #18 vec_resize_allocate_memory (v=,
length_increment=, data_bytes=,

 header_bytes=56, data_align=, numa_id=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:119

 #19 0x7fffb3e1f4e0 in _vec_resize_inline (v=,
length_increment=1, data_bytes=24, header_bytes=48,

 data_align=8, numa_id=255) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170

 #20 acl_plugin_get_lookup_context_index (acl_user_id=1, val1=1, val2=0)

 at
/w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/acl/lookup_context.c:112

 #21 0x7fffb40b4ab5 in abf_itf_attach (fproto=FIB_PROTOCOL_IP4,
policy_id=, priority=0,

 sw_if_index=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:227

 #22 0x7fffb40b7327 in abf_itf_attach_cmd (vm=,
input=, cmd=)

 at
/w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:397

 #23 0x75d6f752 in vlib_cli_dispatch_sub_commands
(vm=0x76012500 , cm=,

 input=0x7fffb5809f60, parent_command_index=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:568

 #24 0x75d6f669 in vlib_cli_dispatch_sub_commands
(vm=0x76012500 ,

 cm=0x76012730 , input=0x7fffb5809f60,
parent_command_index=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:528

 #25 0x75d6edd0 in vlib_cli_input (vm=0x76012500
, input=0x7fffb5809f60,

 function=, function_arg=) at
/w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:667

 #26 0x75de8a3b in unix_cli_process_input (cm=,
cli_file_index=1)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2575

 #27 unix_cli_process (vm=, rt=0x7fffb57c9000, f=)

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2691

 #28 0x75d98cb7 in vlib_process_bootstrap (_a=)

 ---Type  to continue, or q  to quit---

 at /w/workspace/vpp-merge-2005-ubuntu1804/src/vli

Re: [vpp-dev] generic TCP MSS clamping

Re: [vpp-dev] Issue in VRRP functionality when compiling with devtoolset-7 with single worker configuration

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

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

Re: [vpp-dev] vpp19.08.2 crypto_ia32 do not support aes-gcm icv_size 8/12 crypto

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

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

[vpp-dev] Deterministic CGNAT vectors

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

9 matches

Site Navigation

Mail list logo

Footer information