date:20190905

[vpp-dev] VPP 19.08 artifacts deferral notice and 19.08.1 schedule

2019-09-05 Thread Dave Wallace


Dear FD.io Project Members,

[ Note: FD.io -dev email lists BCC'd to reduce noise ]

As discussed in this week's VPP Bi-Weekly Community Meeting, there
is the necessity to introduce a critical fix that breaks VPP API
compatibility.  Therefore we need to defer ALL 19.08 release artifacts
and publish 19.08.1 as soon as practicable.

We apologize in advance for this inconvenience. The details are
in the VPP 19.08.1 release note change set [0].

We plan to merge the API-breaking fix into stable/1908 on Monday
9 September 2019 at 9am CET, and would like to cut the VPP 19.08.1
release on Thursday 12 September. The timing is rather tight to
avoid accumulating too many additional commits to stable/1908 and
to minimize the changes between 19.08 and 19.08.1.

Please review the release note change set [0] and add yourself as
a reviewer to be informed of any changes to the plan.

PTLs, please indicate that your project is okay with these dates or
add your desired dates on-gerrit and save the changes to [0].

We would also kindly ask that even if you are okay with these dates,
that you add 1 or 2 persons from your project as reviewers to [0],
to be able to efficiently communicate any changes to the plan to all
interested project teams.

Thanks,
Andrew & Dave
"Your Friendly VPP Release Managers"

[0] https://gerrit.fd.io/r/#/c/vpp/+/21829/

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

View/Reply Online (#13914): https://lists.fd.io/g/vpp-dev/message/13914
Mute This Topic: https://lists.fd.io/mt/33155962/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 drops while pinging another interface

2019-09-05 Thread Andrew Yourtchenko

It hits the session, so it does pass the L3 acl. Just before ...

--a

> On 5 Sep 2019, at 18:52, Naveen Joy (najoy)  wrote:
> 
> From the trace, it appears like ICMP Echo reply is not permitted by the 
> security-group applied on neutron’s port corresponding to 
> VirtualEthernet0/0/3.
> This could be causing the ICMP reply packet from the firewall to drop.
>lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 
> proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags 
> (invalid) 00 rsvd 0
> 00:53:47:316359: l2-input-feat-arc-end
>   IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
> next_index 17
> 00:53:47:316360: l2-input-acl
>   INACL: sw_if_index 9, next_index 0, table 12, offset -1
> 00:53:47:316361: error-drop
>   rx:VirtualEthernet0/0/3
>  
> -Naveen
>  
> From:  on behalf of Andrew Yourtchenko 
> 
> Date: Thursday, September 5, 2019 at 7:20 AM
> To: Eyle Brinkhuis 
> Cc: "vpp-dev@lists.fd.io" 
> Subject: Re: [vpp-dev] ACL drops while pinging another interface
>  
> Thanks for the traces !
>  
> MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not 
> programmed with the source Mac of your packets.
> 
> “Show acl-plugin macip” will help to see what the acl plugin sees, and if it 
> looks legit, then you can check the classifier tables applied as input acl to 
> verify those are programmed correctly.
>  
> Shout if you get stuck :)
>  
> --a
> 
> On 5 Sep 2019, at 14:18, Eyle Brinkhuis  wrote:
> 
> Hi guys,
>  
> I’m using VPP 19.08 with networking-vpp in an openstack stein environment, 
> where we are busy building an open environment that is specifically built for 
> NFV applications. One of those functions is a firewall setup, where we 
> firewall a customer’s traffic and provide said customer with a ‘clean and 
> safe’ internet connection.
>  
> As such, I am evaluating a VPP setup, which looks very promising. However: in 
> the following scenario, I run into an issue:
>  
> I have a compute host on which I have a firewall running ánd a guest (cirros 
> for now). Setup is as follows:
>  
> 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | 
> VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 
> 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance |
>  
> From the cirros instance pingin the inside interface of the firewall (0/0/3) 
> works like a charm, I wouldn’t have expected any different.
>  
> When I try to ping the outside interface of the firewall (0/0/2), traces show 
> the following:
>  
> 0:53:47:316205: vhost-user-input
>  VirtualEthernet0/0/4 queue 0
>virtio flags:
> INDIRECT Indirect descriptor
>virtio_net_hdr first_desc_len 12
>  flags 0x00 gso_type 0
>  num_buff 0
> 00:53:47:316208: ethernet-input
>   frame: flags 0x1, hw-if-index 7, sw-if-index 10
>   IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e
> 00:53:47:316209: l2-input
>   l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50
> 00:53:47:316210: l2-input-feat-arc
>   IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, 
> next_index 22
> 00:53:47:316211: acl-plugin-in-ip4-l2
>   acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: 
> acl -1 rule 44 trace_bits 8000
>   pkt info    
> 3501909154019091 000a03010008 0200
>lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 
> proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags 
> (invalid) 00 rsvd 0
> 00:53:47:316214: l2-input-feat-arc-end
>   IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
> next_index 17
> 00:53:47:316215: l2-input-acl
>   INACL: sw_if_index 10, next_index 9, table 41, offset 1392
> 00:53:47:316216: l2-learn
>   l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 
> bd_index 3
> 00:53:47:316218: l2-fwd
>   l2-fwd:   sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 
> bd_index 3 result [0x5d509, 9] none
> 00:53:47:316219: l2-output
>   l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 
> 08 00 45 00 00 54 33 9c 40 00 40 01
> 00:53:47:316220: l2-output-feat-arc
>   OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, 
> next_index 11
> 00:53:47:316220: acl-plugin-out-ip4-l2
>   acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 
> 4 rule 2 trace_bits 
>   pkt info    
> 3501909154019091 000902010008 02000006
>lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 
> proto 1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags 
> (invalid) 00 rsvd 0
> 00:53:47:316223: l2-output-feat-arc-end
>   OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, 
> next_index 0
> 00:53:47:316224: VirtualEthernet0/0/3-

Re: [vpp-dev] ACL drops while pinging another interface

2019-09-05 Thread Naveen Joy via Lists.Fd.Io

From the trace, it appears like ICMP Echo reply is not permitted by the 
security-group applied on neutron’s port corresponding to VirtualEthernet0/0/3.
This could be causing the ICMP reply packet from the firewall to drop.

   lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 proto 
1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags (invalid) 00 
rsvd 0

00:53:47:316359: l2-input-feat-arc-end

  IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
next_index 17

00:53:47:316360: l2-input-acl

  INACL: sw_if_index 9, next_index 0, table 12, offset -1

00:53:47:316361: error-drop

  rx:VirtualEthernet0/0/3

-Naveen

From:  on behalf of Andrew Yourtchenko 
Date: Thursday, September 5, 2019 at 7:20 AM
To: Eyle Brinkhuis 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ACL drops while pinging another interface

Thanks for the traces !

MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not 
programmed with the source Mac of your packets.

“Show acl-plugin macip” will help to see what the acl plugin sees, and if it 
looks legit, then you can check the classifier tables applied as input acl to 
verify those are programmed correctly.

Shout if you get stuck :)

--a

On 5 Sep 2019, at 14:18, Eyle Brinkhuis 
mailto:eyle.brinkh...@surfnet.nl>> wrote:
Hi guys,

I’m using VPP 19.08 with networking-vpp in an openstack stein environment, 
where we are busy building an open environment that is specifically built for 
NFV applications. One of those functions is a firewall setup, where we firewall 
a customer’s traffic and provide said customer with a ‘clean and safe’ internet 
connection.

As such, I am evaluating a VPP setup, which looks very promising. However: in 
the following scenario, I run into an issue:

I have a compute host on which I have a firewall running ánd a guest (cirros 
for now). Setup is as follows:

145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | 
VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 
145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance |

From the cirros instance pingin the inside interface of the firewall (0/0/3) 
works like a charm, I wouldn’t have expected any different.

When I try to ping the outside interface of the firewall (0/0/2), traces show 
the following:


0:53:47:316205: vhost-user-input

 VirtualEthernet0/0/4 queue 0

   virtio flags:

INDIRECT Indirect descriptor

   virtio_net_hdr first_desc_len 12

 flags 0x00 gso_type 0

 num_buff 0

00:53:47:316208: ethernet-input

  frame: flags 0x1, hw-if-index 7, sw-if-index 10

  IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e

00:53:47:316209: l2-input

  l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50

00:53:47:316210: l2-input-feat-arc

  IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, 
next_index 22

00:53:47:316211: acl-plugin-in-ip4-l2

  acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: acl 
-1 rule 44 trace_bits 8000

  pkt info    3501909154019091 
000a03010008 0200

   lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 
proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags 
(invalid) 00 rsvd 0

00:53:47:316214: l2-input-feat-arc-end

  IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
next_index 17

00:53:47:316215: l2-input-acl

  INACL: sw_if_index 10, next_index 9, table 41, offset 1392

00:53:47:316216: l2-learn

  l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 
3

00:53:47:316218: l2-fwd

  l2-fwd:   sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 
3 result [0x5d509, 9] none

00:53:47:316219: l2-output

  l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 08 
00 45 00 00 54 33 9c 40 00 40 01

00:53:47:316220: l2-output-feat-arc

  OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, 
next_index 11

00:53:47:316220: acl-plugin-out-ip4-l2

  acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 4 
rule 2 trace_bits 

  pkt info    3501909154019091 
000902010008 02000006

   lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 proto 
1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags (invalid) 00 
rsvd 0

00:53:47:316223: l2-output-feat-arc-end

  OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, next_index 0

00:53:47:316224: VirtualEthernet0/0/3-output

  VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid

  IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e

  ICMP: 145.144.1.84 -> 145.144.1.53

tos 0x00, ttl 64, length 84, checksum 0xe163

fragment id 0x339c, flags DONT_FRAGMENT

  ICMP echo_request checksum 0x9914

00:53:4

Re: [vpp-dev] ACL drops while pinging another interface

2019-09-05 Thread Andrew Yourtchenko

Thanks for the traces !

MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not 
programmed with the source Mac of your packets.

“Show acl-plugin macip” will help to see what the acl plugin sees, and if it 
looks legit, then you can check the classifier tables applied as input acl to 
verify those are programmed correctly.

Shout if you get stuck :)

--a

> On 5 Sep 2019, at 14:18, Eyle Brinkhuis  wrote:
> 
> Hi guys,
>  
> I’m using VPP 19.08 with networking-vpp in an openstack stein environment, 
> where we are busy building an open environment that is specifically built for 
> NFV applications. One of those functions is a firewall setup, where we 
> firewall a customer’s traffic and provide said customer with a ‘clean and 
> safe’ internet connection.
>  
> As such, I am evaluating a VPP setup, which looks very promising. However: in 
> the following scenario, I run into an issue:
>  
> I have a compute host on which I have a firewall running ánd a guest (cirros 
> for now). Setup is as follows:
>  
> 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | 
> VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 
> 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance |
>  
> From the cirros instance pingin the inside interface of the firewall (0/0/3) 
> works like a charm, I wouldn’t have expected any different.
>  
> When I try to ping the outside interface of the firewall (0/0/2), traces show 
> the following:
>  
> 0:53:47:316205: vhost-user-input
>  VirtualEthernet0/0/4 queue 0
>virtio flags:
> INDIRECT Indirect descriptor
>virtio_net_hdr first_desc_len 12
>  flags 0x00 gso_type 0
>  num_buff 0
> 00:53:47:316208: ethernet-input
>   frame: flags 0x1, hw-if-index 7, sw-if-index 10
>   IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e
> 00:53:47:316209: l2-input
>   l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50
> 00:53:47:316210: l2-input-feat-arc
>   IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, 
> next_index 22
> 00:53:47:316211: acl-plugin-in-ip4-l2
>   acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: 
> acl -1 rule 44 trace_bits 8000
>   pkt info    
> 3501909154019091 000a03010008 0200
>lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 
> proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags 
> (invalid) 00 rsvd 0
> 00:53:47:316214: l2-input-feat-arc-end
>   IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
> next_index 17
> 00:53:47:316215: l2-input-acl
>   INACL: sw_if_index 10, next_index 9, table 41, offset 1392
> 00:53:47:316216: l2-learn
>   l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 
> bd_index 3
> 00:53:47:316218: l2-fwd
>   l2-fwd:   sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 
> bd_index 3 result [0x5d509, 9] none
> 00:53:47:316219: l2-output
>   l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 
> 08 00 45 00 00 54 33 9c 40 00 40 01
> 00:53:47:316220: l2-output-feat-arc
>   OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, 
> next_index 11
> 00:53:47:316220: acl-plugin-out-ip4-l2
>   acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 
> 4 rule 2 trace_bits 
>   pkt info    
> 3501909154019091 000902010008 02000006
>lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 
> proto 1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags 
> (invalid) 00 rsvd 0
> 00:53:47:316223: l2-output-feat-arc-end
>   OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, 
> next_index 0
> 00:53:47:316224: VirtualEthernet0/0/3-output
>   VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid 
>   IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e
>   ICMP: 145.144.1.84 -> 145.144.1.53
> tos 0x00, ttl 64, length 84, checksum 0xe163
> fragment id 0x339c, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x9914
> 00:53:47:316225: VirtualEthernet0/0/3-tx
>  VirtualEthernet0/0/3 queue 0
>virtio flags:
> SINGLE_DESC Single descriptor packet
>virtio_net_hdr first_desc_len 4096
>  flags 0x00 gso_type 0
>  num_buff 1
>  
> Packet 3
>  
> 00:53:47:316357: vhost-user-input
>  VirtualEthernet0/0/3 queue 0
>virtio flags:
> INDIRECT Indirect descriptor
>virtio_net_hdr first_desc_len 12
>  flags 0x00 gso_type 0
>  num_buff 0
> 00:53:47:316358: ethernet-input
>   frame: flags 0x1, hw-if-index 6, sw-if-index 9
>   IP4: fa:16:3e:26:3e:0e -> fa:16:3e:93:0c:50
> 00:53:47:316358: l2-input
>   l2-input: sw_if_index 9 dst fa:16:3e:93:0c:50 src fa:16:3e:26:3e:0e
> 00:53:47:316359: l2-input-feat-arc
>   IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype

Re: [vpp-dev] VPP API sometimes hangs on ip_route_details response #vppcapi #vpp_stability #vpp #binapi

2019-09-05 Thread Sylvain CADILHAC

Hello,

Thanks Vratko for the reply.
I’m happy to provide access to an environment where we quite easily reproduce 
the issue, is this might help.

Sylvain

De : "Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)" 

Date : mercredi 4 septembre 2019 à 18:28
À : Sylvain CADILHAC , 
"vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] VPP API sometimes hangs on ip_route_details response 
#vppcapi #vpp_stability #vpp #binapi


Looks like VPP-1753 to me.



I do not have much to add,

heisenbugs are hard to figure out.



Vratko.




From: vpp-dev@lists.fd.io  on behalf of 
sylvain.cadil...@jaguar-network.com 
Sent: Wednesday, September 4, 2019 01:36
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP API sometimes hangs on ip_route_details response 
#vppcapi #vpp_stability #vpp #binapi


Hi vpp-dev,

I'm running a C program which adds/removes interfaces, IPs, routes, etc. to VPP 
via the C API, along with a Python test suite which checks the results of the 
first program multiple times by querying VPP using the Python bindings.
I'm seeing a fairly reproductible issue (when repeating the test suite a number 
of times), where the VPP API thread remains blocked, always after the 
clib_mem_free of a ip_route_details reply message (response to Python).

Traces:

  *   This is VPP 19.08 with slight plugin changes; I can provide the packages 
if needed.
  *   The backtrace is here: 
https://gist.github.com/SCadilhac/bb9ca9600d757b13726e05ae34923c1a#file-backtrace
  *   The startup config file is here: 
https://gist.github.com/SCadilhac/bb9ca9600d757b13726e05ae34923c1a#file-startup-conf
  *   I don't know how to extract the API dump, as the CLI gets unresponsive, 
and the process /tmp/api_post_mortem file remains unwritten.
  *   The gzipped core dump is here: 
http://www.netfishers.onl/downloads/core.24542.gz
Any help is welcome :-). Is there anything I'm obviously doing wrong?
I'm happy to open a Jira issue if this can help.

Thanks,

Sylvain

Ce message et toutes les pièces jointes (ci-après le "message") sont établis à 
l'intention exclusive de ses destinataires. Ce message est strictement 
confidentiel et peut comporter des données à caractère personnel ; si vous 
recevez ce message par erreur, merci de le détruire et d'en avertir 
immédiatement l'expéditeur par retour d'e-mail. Toute utilisation de ce message 
non conforme à sa destination, toute diffusion ou toute publication, totale ou 
partielle, est interdite, sauf autorisation expresse de Jaguar Network. La 
sécurité des communications sur Internet ne peut être garantie et Jaguar 
Network informe en conséquence qu'elle ne peut accepter aucune responsabilité 
quant au contenu de ce message.

This message and all attachments (hereinafter the "message") are intended 
solely for the intended recipients. This message is strictly confidential and 
may include personal data; if you receive this message by mistake, please 
destroy it and notify the sender immediately by return e-mail. Any use of this 
message that does not comply with its intended purpose, any broadcast or any 
publication, total or partial, is prohibited, unless expressly authorized by 
Jaguar Network. Internet communications security cannot be guaranteed and 
Jaguar Network therefore informs that it cannot accept any responsibility for 
the content of this message.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] ACL drops while pinging another interface

2019-09-05 Thread Eyle Brinkhuis

Hi guys,

I’m using VPP 19.08 with networking-vpp in an openstack stein environment, 
where we are busy building an open environment that is specifically built for 
NFV applications. One of those functions is a firewall setup, where we firewall 
a customer’s traffic and provide said customer with a ‘clean and safe’ internet 
connection.

As such, I am evaluating a VPP setup, which looks very promising. However: in 
the following scenario, I run into an issue:

I have a compute host on which I have a firewall running ánd a guest (cirros 
for now). Setup is as follows:

145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | 
VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 
145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance |

From the cirros instance pingin the inside interface of the firewall (0/0/3) 
works like a charm, I wouldn’t have expected any different.

When I try to ping the outside interface of the firewall (0/0/2), traces show 
the following:


0:53:47:316205: vhost-user-input

 VirtualEthernet0/0/4 queue 0

   virtio flags:

INDIRECT Indirect descriptor

   virtio_net_hdr first_desc_len 12

 flags 0x00 gso_type 0

 num_buff 0

00:53:47:316208: ethernet-input

  frame: flags 0x1, hw-if-index 7, sw-if-index 10

  IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e

00:53:47:316209: l2-input

  l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50

00:53:47:316210: l2-input-feat-arc

  IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, 
next_index 22

00:53:47:316211: acl-plugin-in-ip4-l2

  acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: acl 
-1 rule 44 trace_bits 8000

  pkt info    3501909154019091 
000a03010008 0200

   lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 
proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags 
(invalid) 00 rsvd 0

00:53:47:316214: l2-input-feat-arc-end

  IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
next_index 17

00:53:47:316215: l2-input-acl

  INACL: sw_if_index 10, next_index 9, table 41, offset 1392

00:53:47:316216: l2-learn

  l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 
3

00:53:47:316218: l2-fwd

  l2-fwd:   sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 
3 result [0x5d509, 9] none

00:53:47:316219: l2-output

  l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 08 
00 45 00 00 54 33 9c 40 00 40 01

00:53:47:316220: l2-output-feat-arc

  OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, 
next_index 11

00:53:47:316220: acl-plugin-out-ip4-l2

  acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 4 
rule 2 trace_bits 

  pkt info    3501909154019091 
000902010008 02000006

   lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 proto 
1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags (invalid) 00 
rsvd 0

00:53:47:316223: l2-output-feat-arc-end

  OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, next_index 0

00:53:47:316224: VirtualEthernet0/0/3-output

  VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid

  IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e

  ICMP: 145.144.1.84 -> 145.144.1.53

tos 0x00, ttl 64, length 84, checksum 0xe163

fragment id 0x339c, flags DONT_FRAGMENT

  ICMP echo_request checksum 0x9914

00:53:47:316225: VirtualEthernet0/0/3-tx

 VirtualEthernet0/0/3 queue 0

   virtio flags:

SINGLE_DESC Single descriptor packet

   virtio_net_hdr first_desc_len 4096

 flags 0x00 gso_type 0

 num_buff 1



Packet 3



00:53:47:316357: vhost-user-input

 VirtualEthernet0/0/3 queue 0

   virtio flags:

INDIRECT Indirect descriptor

   virtio_net_hdr first_desc_len 12

 flags 0x00 gso_type 0

 num_buff 0

00:53:47:316358: ethernet-input

  frame: flags 0x1, hw-if-index 6, sw-if-index 9

  IP4: fa:16:3e:26:3e:0e -> fa:16:3e:93:0c:50

00:53:47:316358: l2-input

  l2-input: sw_if_index 9 dst fa:16:3e:93:0c:50 src fa:16:3e:26:3e:0e

00:53:47:316359: l2-input-feat-arc

  IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 9, 
next_index 22

00:53:47:316359: acl-plugin-in-ip4-l2

  acl-plugin: lc_index: -1, sw_if_index 9, next index 1, action: 3, match: acl 
-1 rule 97 trace_bits 8000

  pkt info    5401909135019091 
00090301 0200

   lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 proto 
1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags (invalid) 00 
rsvd 0

00:53:47:316359: l2-input-feat-arc-end

  IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, 
nex

Re: [vpp-dev] vppcom_session_connect blocking or non blocking

2019-09-05 Thread Max A. via Lists.Fd.Io

Hi Florin,

I'll check it out soon.

Thank you very much!


>Четверг,  5 сентября 2019, 1:04 +03:00 от Florin Coras 
>:
>
>Hi Max, 
>
>Here’s the patch that allows non-blocking connects [1]. 
>
>Florin
>
>[1]  https://gerrit.fd.io/r/c/vpp/+/21610
>
>>On Aug 15, 2019, at 7:41 AM, Florin Coras via Lists.Fd.Io < 
>>fcoras.lists=gmail@lists.fd.io > wrote:
>>Hi Max,
>>
>>Not at this time. It should be possible with a few changes for nonblocking 
>>sessions. I’ll add it to my list, in case nobody else beats me to it. 
>>
>>Florin
>>
>>>On Aug 15, 2019, at 2:47 AM, Max A. via Lists.Fd.Io < 
>>>max1976=mail...@lists.fd.io > wrote:
>>>
>>>Hello,
>>>
>>>Can vppcom_session_connect() function run in non-blocking mode? I see that 
>>>there is a wait for the connection result in the 
>>>vppcom_wait_for_session_state_change function.  Is it possible to get the 
>>>result of the connection using vppcom_epoll_wait?
>>>
>>>Thanks.
>>>-=-=-=-=-=-=-=-=-=-=-=-
>>>Links: You receive all messages sent to this group.
>>>
>>>View/Reply Online (#13745):  https://lists.fd.io/g/vpp-dev/message/13745
>>>Mute This Topic:  https://lists.fd.io/mt/32885087/675152
>>>Group Owner:  vpp-dev+ow...@lists.fd.io
>>>Unsubscribe:  https://lists.fd.io/g/vpp-dev/unsub  [ fcoras.li...@gmail.com ]
>>>-=-=-=-=-=-=-=-=-=-=-=-
>>
>>-=-=-=-=-=-=-=-=-=-=-=-
>>Links: You receive all messages sent to this group.
>>
>>View/Reply Online (#13747):  https://lists.fd.io/g/vpp-dev/message/13747
>>Mute This Topic:  https://lists.fd.io/mt/32885087/675152
>>Group Owner:  vpp-dev+ow...@lists.fd.io
>>Unsubscribe:  https://lists.fd.io/g/vpp-dev/unsub  [ fcoras.li...@gmail.com ]
>>-=-=-=-=-=-=-=-=-=-=-=-
>


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

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

[vpp-dev] VPP 19.08 artifacts deferral notice and 19.08.1 schedule

Re: [vpp-dev] ACL drops while pinging another interface

Re: [vpp-dev] ACL drops while pinging another interface

Re: [vpp-dev] ACL drops while pinging another interface

Re: [vpp-dev] VPP API sometimes hangs on ip_route_details response #vppcapi #vpp_stability #vpp #binapi

[vpp-dev] ACL drops while pinging another interface

Re: [vpp-dev] vppcom_session_connect blocking or non blocking

7 matches

Site Navigation

Mail list logo

Footer information