[vpp-dev] Recall: vcl preload usage error

[Liu, Chunmei]

Liu, Chunmei would like to recall the message, "[vpp-dev] vcl preload usage 
error".
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vcl preload usage error

[Florin Coras]

Hi Chunmei, 

The first error says you’re trying to bind multiple times to the same address, 
which is not supported. You’re getting the second error because you don’t have 
a fib path to the destination of your connect. 

Hope this helps, 
Florin

> On Jan 17, 2018, at 3:55 PM, Liu, Chunmei  wrote:
> 
> Hi all, 
>  
>  I am a novice at vpp, I am trying to use 
> LD_PRELOAD=/../../libvcl_ldpreload.so to run a native app with vpp, I got the 
> following error:
> vl_api_bind_sock_reply_t_handler:1000: [28874] ERROR: vpp handle 0x0, sid 4: 
> bind failed: Address in use (-105)
> 2018-01-17 15:18:41.187 7fffe2b83700 -1 PosixStack listen unable to listen on 
> 0.0.0.0:6800/0: (111) Connection refused
> vl_api_bind_sock_reply_t_handler:1000: [28874] ERROR: vpp handle 0x0, sid 5: 
> bind failed: Address in use (-105)
> 2018-01-17 15:18:41.187 7fffe2b83700 -1 PosixStack listen unable to listen on 
> 0.0.0.0:6800/0: (111) Connection refused
>  
> And :
> /usr/bin/vpp[29054]: transport_alloc_local_endpoint:293: no resolving 
> interface for X.X.X.X
> /usr/bin/vpp[29054]: vnet_connect: connect failed
>  
> What I missed in configure vpp? 
>  
> Thanks a lot!
> -Chunmei
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Port mirroring support in vpp

[John Lo (loj)]

Hi Juraj,

Can you check what “show node counters” or “sho run” give you? Do you see any 
evidence of span nodes being active or any packet drops? I think the output 
interface for mirrored packets in L2 also needs to be in L2 mode as well.

You can find SPAN test cases in test/test_span.py to check how it is set up and 
tested. The test cases include L2 ones with mirrored packet output to VLAN 
sub-interfaces and VXLAN tunnels.

Regards,
John

From: Juraj Linkeš [mailto:juraj.lin...@pantheon.tech]
Sent: Thursday, January 18, 2018 11:14 AM
To: John Lo (loj) ; Damjan Marion (damarion) 

Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Port mirroring support in vpp

Hi John,

Thanks for the summary. I’ve been using 1710 when I wrote the e-mail, but I’ve 
tried 1801 and I could configure span on a veth interface (that’s my setup for 
now), but I didn’t see any traffic on the destination port (I tried loopback 
bvi and an L2 and L3 physical interface as destinations) - nothing in show 
trace and the interface counters didn’t go up. How do I verify that the traffic 
is mirrored onto the destination port? Is there some constraint on what the 
destination port can be?

Thanks,
Juraj

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Thursday, January 18, 2018 3:20 AM
To: Damjan Marion (damarion) >; 
Juraj Linkeš >
Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Port mirroring support in vpp

For VPP 18.01 and master, SPAN has been enhanced to allow port mirroring for 
interface in L2 mode such as ones in bridge domains. There is a “L2” argument 
added to the SPAN CLI/API which allow any interface, including vHost, to have 
packet replicated on its L2 input and/or output paths and be sent to the 
specified destination interface.

The CLI syntax for SPAN is now:
DBGvpp# set int span ?
  set interface span … set interface span  [l2] {disable | destination 
 [both|rx|tx]}

If you specify the “l2” keyword, packet replication will be performed on L2 
input and/or output packets on the specified interface. It should work for any 
interface in any bridge domain except BVI. For the BVI, SPAN can only replicate 
L2 input (and not output) packets.

Regards,
John

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Damjan Marion (damarion)
Sent: Wednesday, January 17, 2018 8:17 PM
To: Juraj Linkeš >
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Port mirroring support in vpp

Have you tried with SPAN?

On 17 Jan 2018, at 10:07, Juraj Linkeš 
> wrote:

Hi VPP devs,

I’m trying to figure out whether it’s possible to set up port mirroring on a 
vhost-user port in VPP. The case I’m trying to make work is simple: I have 
traffic between two vms (using vhost-user ports) and I want to listen to that 
traffic, replicate it and send it somewhere else (to an interface, but 
preferably an ip).

I’ve looked into what’s available in VPP and there is some support for SPAN, 
but doesn’t seem to work with vhost-user interfaces (I wasn’t able to configure 
it). In fact, it only seems to be configurable on physical interfaces. Is this 
accurate?

Then there are clis for lawful intercept (set li), but the configuration 
doesn’t seem to do anything. Is this supported?

Is there some other way to achieve port mirroring on vhost-user interfaces in 
case the two above are not supported? It can be any unwieldy/hacky way (maybe 
setting something up with multicast?).

Thanks,
Juraj
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Port mirroring support in vpp

[Juraj Linkeš]

Hi John,

Thanks for the summary. I’ve been using 1710 when I wrote the e-mail, but I’ve 
tried 1801 and I could configure span on a veth interface (that’s my setup for 
now), but I didn’t see any traffic on the destination port (I tried loopback 
bvi and an L2 and L3 physical interface as destinations) - nothing in show 
trace and the interface counters didn’t go up. How do I verify that the traffic 
is mirrored onto the destination port? Is there some constraint on what the 
destination port can be?

Thanks,
Juraj

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Thursday, January 18, 2018 3:20 AM
To: Damjan Marion (damarion) ; Juraj Linkeš 

Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Port mirroring support in vpp

For VPP 18.01 and master, SPAN has been enhanced to allow port mirroring for 
interface in L2 mode such as ones in bridge domains. There is a “L2” argument 
added to the SPAN CLI/API which allow any interface, including vHost, to have 
packet replicated on its L2 input and/or output paths and be sent to the 
specified destination interface.

The CLI syntax for SPAN is now:
DBGvpp# set int span ?
  set interface span … set interface span  [l2] {disable | destination 
 [both|rx|tx]}

If you specify the “l2” keyword, packet replication will be performed on L2 
input and/or output packets on the specified interface. It should work for any 
interface in any bridge domain except BVI. For the BVI, SPAN can only replicate 
L2 input (and not output) packets.

Regards,
John

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Damjan Marion (damarion)
Sent: Wednesday, January 17, 2018 8:17 PM
To: Juraj Linkeš >
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Port mirroring support in vpp

Have you tried with SPAN?

On 17 Jan 2018, at 10:07, Juraj Linkeš 
> wrote:

Hi VPP devs,

I’m trying to figure out whether it’s possible to set up port mirroring on a 
vhost-user port in VPP. The case I’m trying to make work is simple: I have 
traffic between two vms (using vhost-user ports) and I want to listen to that 
traffic, replicate it and send it somewhere else (to an interface, but 
preferably an ip).

I’ve looked into what’s available in VPP and there is some support for SPAN, 
but doesn’t seem to work with vhost-user interfaces (I wasn’t able to configure 
it). In fact, it only seems to be configurable on physical interfaces. Is this 
accurate?

Then there are clis for lawful intercept (set li), but the configuration 
doesn’t seem to do anything. Is this supported?

Is there some other way to achieve port mirroring on vhost-user interfaces in 
case the two above are not supported? It can be any unwieldy/hacky way (maybe 
setting something up with multicast?).

Thanks,
Juraj
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Create an arc

[Neale Ranns (nranns)]

In order to prevent the calculation of the checksum twice your node would need 
to run instead of ip4-rewrite - is that your intention? – there’s quite a bit 
more going on in that node! If instead you want your node to run as well as 
ip4-rewrite, then it can be an output-feature (arc=ip4-output), where it will 
receive all packets egressing through that interface post rewrite encapsulation.

/neale


-Original Message-
From: korian edeline 
Date: Thursday, 18 January 2018 at 12:36
To: "Neale Ranns (nranns)" , "Dave Barach (dbarach)" 
, "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Create an arc

Hello Neale, Dave,

Thanks for your answers.

I would like to catch all (not on a prefix basis) traffic to-be-forwarded.
- I would need the TX sw_if_index, so i think the nodes should be placed 
after ip4-lookup.
- i have to be before ip4-rewrite, not to compute checksums 2 times.

Right now, my nodes are placed before lookup, via ip4-unicast feature 
arc and they can be enabled/disabled via vnet_feature_enable_disable. 
Something similar, but after lookup, would be really convenient.

Regards,
Korian

On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:
> Hi Korian,
>
> Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and 
really to interface-output) is best achieved by following the DPO architecture. 
You can read a little about it here:
>https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs
>
> Step one is to implement a new DPOs to represent your two new nodes. 
You’ll find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ 
the IP prefix via your DPO. The means for that is, e.g, from 
vnet/bier/bier_table.c:
>
>  bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
>,
>FIB_SOURCE_BIER,
>
FIB_ENTRY_FLAG_EXCLUSIVE,
>);
>
> the rather badly named EXCLUSIVE flag means the caller is providing the 
DPO and so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
identifies ‘who’ is providing the forwarding information (the DPO) and thus the 
relative priority of that information. There is a simple linear priority scheme 
among the sources enumerated by fib_source_t.
> Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
followed in the data-plane. The FIB API above automatically stacks the 
load_balance_t DPO (which is the result of the lookup) on your DPO passed.
>
> note that the above provides you with ‘override’ semantics, i.e. for a 
given prefix you can override (assuming your source has higher priority) the 
existing forwarding information for that prefix. If instead your requirements 
are to apply further rules/checks/replications on the packets before they are 
forwarded using the existing information, then this is what I call 
‘interposition’. I have an outstanding patch for this:
>https://gerrit.fd.io/r/#/c/9336/
> I’ll try and get it finished soon.
>
> The last issue to consider is whether your override or interposition 
needs to affect only the prefix you specify in the call to 
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
covers. For example, if you specify 10.0.0.0/24, and some other source 
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
order to ‘push’ your forwarding down to all longer mask prefixes in the 
sub-tree one needs to explicitly specify this. Again, this is an outstanding 
patch:
>   https://gerrit.fd.io/r/#/c/9477/
>
>
> Having said all that, if what you are after Is not running your feature 
on a per-prefix basis, but instead on a per-output interface basis, then you 
want the ip4-output feature arc ☺
>
> hth,
> neale
>
>
> -Original Message-
> From: "Dave Barach (dbarach)" 
> Date: Wednesday, 17 January 2018 at 16:21
> To: korian edeline , "vpp-dev@lists.fd.io" 
, "Neale Ranns (nranns)" 
> Subject: RE: [vpp-dev] Create an arc
>
>  Dear Korian,
>  
>  Steering traffic from ip4_lookup to  is easily 
accomplished by setting the fib result [dpo->dpoi_next_node] to send matching 
traffic where you want it to go.
>  
>  Add an arc from ip4/6_lookup to  by calling 
vlib_node_add_next(...) to create the arc, then create fib entries with 
dpoi_next_node set to the returned next_index.
>  
>  This is not a feature arc problem. Attempting to solve it as such 
will cause no end of 

Re: [vpp-dev] Create an arc

[korian edeline]

Hello Neale, Dave,

Thanks for your answers.

I would like to catch all (not on a prefix basis) traffic to-be-forwarded.
- I would need the TX sw_if_index, so i think the nodes should be placed 
after ip4-lookup.

- i have to be before ip4-rewrite, not to compute checksums 2 times.

Right now, my nodes are placed before lookup, via ip4-unicast feature 
arc and they can be enabled/disabled via vnet_feature_enable_disable. 
Something similar, but after lookup, would be really convenient.


Regards,
Korian

On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:

Hi Korian,

Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and really to 
interface-output) is best achieved by following the DPO architecture. You can 
read a little about it here:
   https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs

Step one is to implement a new DPOs to represent your two new nodes. You’ll 
find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ the IP 
prefix via your DPO. The means for that is, e.g, from vnet/bier/bier_table.c:

 bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
   ,
   FIB_SOURCE_BIER,
   FIB_ENTRY_FLAG_EXCLUSIVE,
   );

the rather badly named EXCLUSIVE flag means the caller is providing the DPO and 
so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
identifies ‘who’ is providing the forwarding information (the DPO) and thus the 
relative priority of that information. There is a simple linear priority scheme 
among the sources enumerated by fib_source_t.
Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
followed in the data-plane. The FIB API above automatically stacks the 
load_balance_t DPO (which is the result of the lookup) on your DPO passed.

note that the above provides you with ‘override’ semantics, i.e. for a given 
prefix you can override (assuming your source has higher priority) the existing 
forwarding information for that prefix. If instead your requirements are to 
apply further rules/checks/replications on the packets before they are 
forwarded using the existing information, then this is what I call 
‘interposition’. I have an outstanding patch for this:
   https://gerrit.fd.io/r/#/c/9336/
I’ll try and get it finished soon.

The last issue to consider is whether your override or interposition needs to 
affect only the prefix you specify in the call to 
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
covers. For example, if you specify 10.0.0.0/24, and some other source 
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
order to ‘push’ your forwarding down to all longer mask prefixes in the 
sub-tree one needs to explicitly specify this. Again, this is an outstanding 
patch:
  https://gerrit.fd.io/r/#/c/9477/


Having said all that, if what you are after Is not running your feature on a 
per-prefix basis, but instead on a per-output interface basis, then you want 
the ip4-output feature arc ☺

hth,
neale


-Original Message-
From: "Dave Barach (dbarach)" 
Date: Wednesday, 17 January 2018 at 16:21
To: korian edeline , "vpp-dev@lists.fd.io" , 
"Neale Ranns (nranns)" 
Subject: RE: [vpp-dev] Create an arc

 Dear Korian,
 
 Steering traffic from ip4_lookup to  is easily accomplished by setting the fib result [dpo->dpoi_next_node] to send matching traffic where you want it to go.
 
 Add an arc from ip4/6_lookup to  by calling vlib_node_add_next(...) to create the arc, then create fib entries with dpoi_next_node set to the returned next_index.
 
 This is not a feature arc problem. Attempting to solve it as such will cause no end of trouble.
 
 Neale, please jump in as needed...
 
 HTH... Dave
 
 -Original Message-

 From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of korian edeline
 Sent: Wednesday, January 17, 2018 9:30 AM
 To: vpp-dev@lists.fd.io
 Subject: [vpp-dev] Create an arc
 
 Hi all,
 
 Here is the deal:
 
 I have 2 nodes (my-node-1, my-node-2),  I would like my-node-1 to receive packets from ip4-lookup, forwarding to either ip4-rewrite, error-drop or my-node-2. my-node-2 should only receive from my-node-1 and forward to ip4-rewrite or error-drop.
 
 If I put them BEFORE ip4-lookup, i can use pre-built arc ip4-unicast and everything works perfect. But i figured that if i want them after ip4-lookup, i have to create my own arc. So here is what i have, plus replacing occurences of "ip4-unicast" by "my-arc".
 
 VNET_FEATURE_ARC_INIT (my_arc, static) = {

.arc_name = "my-arc,
.start_nodes = 

Re: [vpp-dev] Create an arc

[Neale Ranns (nranns)]

Hi Korian,

Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and really to 
interface-output) is best achieved by following the DPO architecture. You can 
read a little about it here:
  https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs

Step one is to implement a new DPOs to represent your two new nodes. You’ll 
find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ the IP 
prefix via your DPO. The means for that is, e.g, from vnet/bier/bier_table.c:

bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
  ,
  FIB_SOURCE_BIER,
  FIB_ENTRY_FLAG_EXCLUSIVE,
  );

the rather badly named EXCLUSIVE flag means the caller is providing the DPO and 
so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
identifies ‘who’ is providing the forwarding information (the DPO) and thus the 
relative priority of that information. There is a simple linear priority scheme 
among the sources enumerated by fib_source_t.
Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
followed in the data-plane. The FIB API above automatically stacks the 
load_balance_t DPO (which is the result of the lookup) on your DPO passed.

note that the above provides you with ‘override’ semantics, i.e. for a given 
prefix you can override (assuming your source has higher priority) the existing 
forwarding information for that prefix. If instead your requirements are to 
apply further rules/checks/replications on the packets before they are 
forwarded using the existing information, then this is what I call 
‘interposition’. I have an outstanding patch for this:
  https://gerrit.fd.io/r/#/c/9336/
I’ll try and get it finished soon.

The last issue to consider is whether your override or interposition needs to 
affect only the prefix you specify in the call to 
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
covers. For example, if you specify 10.0.0.0/24, and some other source 
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
order to ‘push’ your forwarding down to all longer mask prefixes in the 
sub-tree one needs to explicitly specify this. Again, this is an outstanding 
patch:
 https://gerrit.fd.io/r/#/c/9477/


Having said all that, if what you are after Is not running your feature on a 
per-prefix basis, but instead on a per-output interface basis, then you want 
the ip4-output feature arc ☺

hth,
neale


-Original Message-
From: "Dave Barach (dbarach)" 
Date: Wednesday, 17 January 2018 at 16:21
To: korian edeline , "vpp-dev@lists.fd.io" 
, "Neale Ranns (nranns)" 
Subject: RE: [vpp-dev] Create an arc

Dear Korian,

Steering traffic from ip4_lookup to  is easily accomplished by 
setting the fib result [dpo->dpoi_next_node] to send matching traffic where you 
want it to go. 

Add an arc from ip4/6_lookup to  by calling 
vlib_node_add_next(...) to create the arc, then create fib entries with 
dpoi_next_node set to the returned next_index.

This is not a feature arc problem. Attempting to solve it as such will 
cause no end of trouble. 

Neale, please jump in as needed...

HTH... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of korian edeline
Sent: Wednesday, January 17, 2018 9:30 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Create an arc

Hi all,

Here is the deal:

I have 2 nodes (my-node-1, my-node-2),  I would like my-node-1 to receive 
packets from ip4-lookup, forwarding to either ip4-rewrite, error-drop or 
my-node-2. my-node-2 should only receive from my-node-1 and forward to 
ip4-rewrite or error-drop.

If I put them BEFORE ip4-lookup, i can use pre-built arc ip4-unicast and 
everything works perfect. But i figured that if i want them after ip4-lookup, i 
have to create my own arc. So here is what i have, plus replacing occurences of 
"ip4-unicast" by "my-arc".

VNET_FEATURE_ARC_INIT (my_arc, static) = {
   .arc_name = "my-arc,
   .start_nodes = VNET_FEATURES ("ip4-lookup"),
   .arc_index_ptr = _main.feature_arc_index };

What am i missing  ?

Thanks

Korian

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Heads up: VPPAPIGEN rewrite

[Ole Troan]

Hi Jon,

> Can we add to the "Future Plans" list?
> I would like to see it draw a correlation between a message's actual
> list of fields and the attempt at a documentation for those fields.
> Specifically, there always seems to be some discrepancy and it is
> hard to tell which to believe without then going and reading the code.
> If the fields and doc lines for the fields at least agreed on which fields
> were present, that would be a start.

I find embedded documentation (and excessive comments) problematic for that 
exact reason.
We're never going to make them consistent.

Stepping back a little; I think we agree that the API, being the main interface 
outside of VPP, should have good documentation.
I don't think doxygen tags in the .api files can ever be that.
If you agree with that, do you have better suggestions?
Given that we have multiple language bindings, interactive documentation like 
what Swagger has might be one option?

Best regards,
Ole




signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev