Re: [vpp-dev] Some NAT API Error Values

[Jon Loeliger via lists.fd.io]

On Wed, Nov 23, 2022 at 12:25 PM filvarga  wrote:

> Hi,
>
> Thank you for your notes and pointing out the issue. Feel free to submit
> any changes in the future and add appropriate people to your review (based
> on maintainers list).
>

Thanks, will do!

For now I am posting a quick fix. As the nat44-ed control plane is
> undergoing a continuous huge refactor I wouldn't advise too much diverting
> from its current state.\
>

I might point out that this applies to both ED and EI.  They both display
the same issues.


> Better solution here is to check the return value of enable / disable
> calls and then set rv appropriately.
>

Exactly.  But in this case I couldn't because it was buried in a macro that
didn't return.


> For now (based on return codes from vnet/error.h) I will use these
> VNET_API_ERROR_FEATURE_DISABLED
> VNET_API_ERROR_UNSUPPORTED
> for enable/disable api errors rather than introducing something new that
> can get removed in near future.
>

Those error values miss the important case of identifying the case where
one is
trying to enable the already-enabled feature.  We need to know and identify
that
case, just as many of the other Features do.

Thanks,
jdl

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

[vpp-dev] Some NAT API Error Values

[Jon Loeliger via lists.fd.io]

Hi VPPeople,

I would like to open a discussion about some strange code and return values
from a few of the NAT CLI and API interface functions.

My quest for a reasonable handling when my management plane attempted to
enable an already-enabled NAT 44 ED feature was handled poorly.  It turns
out,
rather than a negative API return value with an error indicating that the
feature
was already enabled, nor did it return 0 indicating that all was well.
Instead it
returned a positive 1 value.  As there is no indication of return value in
the reply
API call, a normal, negative value was expected.

When I first read through
the vl_api_nat44_ed_plugin_enable_disable_t_handler()
and the underlying nat44_plugin_enable() code, I couldn't see where it even
returned anything other than a straight open-coded 0 return value.

A closer read showed two seriously weird coding issues, both related.  At
the beginning
of nat44_plugin_enable() we find this code from
src/plugin/nat/nat44_ed_api.c
and nat44_ed.c:

int
nat44_plugin_enable (nat44_config_t c)
{
  snat_main_t *sm = _main;

  fail_if_enabled ();

  sm->forwarding_enabled = 0;
  sm->mss_clamping = 0;
  ...

The apparent function fail_if_enabled() isn't a function at all:

#define fail_if_enabled()
  \
  do
   \
{
  \
  snat_main_t *sm = _main;
  \
  if (PREDICT_FALSE (sm->enabled))
   \
{
  \
  nat_log_err ("plugin enabled");
  \
  return 1;
  \
}
  \
}
  \
  while (0)

It is a single compound statement with the hidden side effect
of returning directly out of the containing function with, get
this, a return value of 1.  This return value is then used in
turn directly as the error return value for an API call:

static void
vl_api_nat44_ed_plugin_enable_disable_t_handler (
  vl_api_nat44_ed_plugin_enable_disable_t *mp)
{
...
  if (mp->enable)
{
  if ((mp->flags & NAT44_API_IS_STATIC_MAPPING_ONLY) ||
  (mp->flags & NAT44_API_IS_CONNECTION_TRACKING))
{
  rv = VNET_API_ERROR_UNSUPPORTED;
}
  else
{
  c.sessions = ntohl (mp->sessions);
  c.inside_vrf = ntohl (mp->inside_vrf);
  c.outside_vrf = ntohl (mp->outside_vrf);

  rv = nat44_plugin_enable (c);
}
}
...

OK, I am proposing two fixes here.

First, hiding unexpected control flow in a #define like this is bad for
many reasons.
Allowing for a nominal function to determine if the feature is already
enabled
or not is fine.  It should look like an actual inline function with a
legitimate return value.
It should likely be a TRUE/FALSE "is enabled" testing function,  It should
probably
leave the interpretation of that value to the caller.  That is, the caller
should issue error
messages and generate proper return codes accordingly.

Second, the actual return values for the API should be both listed in the
API error values
enumeration and be negative for errors.  If there is a need, and I
maintainer there is, for
an error code that indicates "already enabled", it should be added if not
already present.

Anyone have any problem with me submitting patches to fix these issues?

Thanks,
jdl

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

Re: [vpp-dev] Wireguard Peer Route Table Questions

[Jon Loeliger via lists.fd.io]

Hey VPP-ers,

I have posted a suggested solution to this issue here:

https://gerrit.fd.io/r/c/vpp/+/35896

Feel free to review!

jdl


On Mon, Apr 4, 2022 at 12:45 PM Jon Loeliger via lists.fd.io  wrote:

> Folks,
>
> I have a scenario where setting up a Wireguard interface and peer causes
> VPP
> to segfault.  I think the situation is simply that the function
>
> always_inline uword
> wg_output_tun_inline (vlib_main_t *vm, vlib_node_runtime_t *node,
>   vlib_frame_t *frame, u8 is_ip4, u16 async_next_node)
>
> fails to find a proper peer for an adj_index of a packet in this code:
>
>   adj_index = vnet_buffer (b[0])->ip.adj_index[VLIB_TX];
>
>   if (PREDICT_FALSE (last_adj_index != adj_index))
> {
>   peeri = wg_peer_get_by_adj_index (adj_index);
>   peer = wg_peer_get (peeri);
> }
>
> Should it instead see a lack of peer (and route?) and thus simply
> drop the packet instead?
>
> The segfault happens in  wg_peer_get_by_adj_index() because a
> NULL vector was never established with a peer:
>
> static inline index_t
> wg_peer_get_by_adj_index (index_t ai)
> {
>return (wg_peer_by_adj_index[ai]);
> }
>
> That should have been setup here:
>
> wg_peer_if_adj_change (index_t peeri, void *data)
> {
>   adj_index_t *adj_index = data;
>   adj_midchain_fixup_t fixup;
>   ip_adjacency_t *adj;
>   wg_peer_t *peer;
>   fib_prefix_t *allowed_ip;
>
>   adj = adj_get (*adj_index);
>
>   peer = wg_peer_get (peeri);
>   vec_foreach (allowed_ip, peer->allowed_ips)
> {
>   if (fib_prefix_is_cover_addr_46 (allowed_ip,
>>sub_type.nbr.next_hop))
> {
>   vec_add1 (peer->adj_indices, *adj_index);
>   vec_validate_init_empty (wg_peer_by_adj_index, *adj_index,
>INDEX_INVALID);
>   wg_peer_by_adj_index[*adj_index] = peer - wg_peer_pool;
>
>
> Dumping core by an invalid vector reference of wg_peer_by_adj_index[] is
> a poor way to tell me that a route isn't set up properly? :-). My question
> is,
> where should we catch this error and prevent that?
>
> Thanks,
> jdl
>
>
> 
>
>

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

[vpp-dev] Wireguard Peer Route Table Questions

[Jon Loeliger via lists.fd.io]

Folks,

I have a scenario where setting up a Wireguard interface and peer causes VPP
to segfault.  I think the situation is simply that the function

always_inline uword
wg_output_tun_inline (vlib_main_t *vm, vlib_node_runtime_t *node,
  vlib_frame_t *frame, u8 is_ip4, u16 async_next_node)

fails to find a proper peer for an adj_index of a packet in this code:

  adj_index = vnet_buffer (b[0])->ip.adj_index[VLIB_TX];

  if (PREDICT_FALSE (last_adj_index != adj_index))
{
  peeri = wg_peer_get_by_adj_index (adj_index);
  peer = wg_peer_get (peeri);
}

Should it instead see a lack of peer (and route?) and thus simply
drop the packet instead?

The segfault happens in  wg_peer_get_by_adj_index() because a
NULL vector was never established with a peer:

static inline index_t
wg_peer_get_by_adj_index (index_t ai)
{
   return (wg_peer_by_adj_index[ai]);
}

That should have been setup here:

wg_peer_if_adj_change (index_t peeri, void *data)
{
  adj_index_t *adj_index = data;
  adj_midchain_fixup_t fixup;
  ip_adjacency_t *adj;
  wg_peer_t *peer;
  fib_prefix_t *allowed_ip;

  adj = adj_get (*adj_index);

  peer = wg_peer_get (peeri);
  vec_foreach (allowed_ip, peer->allowed_ips)
{
  if (fib_prefix_is_cover_addr_46 (allowed_ip,
   >sub_type.nbr.next_hop))
{
  vec_add1 (peer->adj_indices, *adj_index);
  vec_validate_init_empty (wg_peer_by_adj_index, *adj_index,
   INDEX_INVALID);
  wg_peer_by_adj_index[*adj_index] = peer - wg_peer_pool;


Dumping core by an invalid vector reference of wg_peer_by_adj_index[] is
a poor way to tell me that a route isn't set up properly? :-). My question
is,
where should we catch this error and prevent that?

Thanks,
jdl

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

[Jon Loeliger via lists.fd.io]

On Sun, Dec 13, 2020 at 6:15 AM Damjan Marion via lists.fd.io  wrote:

>
> Hi,
>
> I was playing a bit with clang-format as replacement to gnu indent which
> we use today[1].
>
> While it is impossible to render exact same result like gnu indent, good
> thing is that clang-format can be used only on lines which are changed in
> the diff so no major reformat is needed. My patch deos exactly that.
>

I would welcome any change away from the absolutely horrendous Gnu coding
style!

jdl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18389): https://lists.fd.io/g/vpp-dev/message/18389
Mute This Topic: https://lists.fd.io/mt/78925374/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] Message posting policy change

[Jon Loeliger via lists.fd.io]

On Wed, Dec 16, 2020 at 6:47 AM Dave Barach  wrote:

> Folks,
>
>
>
> Any objections to reconfiguring the vpp-dev@lists.fd.io group to reject
> messages from non-list-members?
>
>
>
> Thanks... Dave
>

Ja, do it.

jdl

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

Re: [vpp-dev] #vpp #vpp-memif #vppcom

[Jon Loeliger via lists.fd.io]

On Fri, Dec 11, 2020 at 3:13 PM  wrote:

> in our application I have to send out multicast packets, but the packet is
> getting dropped in vpp
>
> #vpp #vpp-memif #vppcom


Folks,

You know, these subject lines are near meaningless.
Could we please have real English descriptions, questions or useful phrases?

Thank you,
jdl

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

Re: [vpp-dev] bihash change

[Jon Loeliger via lists.fd.io]

On Wed, Sep 30, 2020 at 8:11 AM Damjan Marion via lists.fd.io  wrote:

>
> Just a heads-up on under-the-hood change[1] which is merged few minutes
> ago and which affects all features that use bihash.
> Now, bihash is allocating memory from the (main) heap, instead of
> mmap()-ing it’s own alloc arena.
>
> [ ...]
> Damjan
>

Damjan,

Does this include the bihash and heap use within the Classifier code as
well?
Or just the templated bihash from the library?

Thanks,
jdl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17617): https://lists.fd.io/g/vpp-dev/message/17617
Mute This Topic: https://lists.fd.io/mt/77216768/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] table lookup api?

[Jon Loeliger via lists.fd.io]

On Tue, Sep 29, 2020 at 9:31 AM  wrote:

> Hi Jon,
>
>
>
> I see, thanks.  I have to go back to the drawing board.
>
>
>
> I am developing a P4 to VPP compiler.  If VPP has any API to create a
> table and lookup the table, it would ease compiler development.  I am
> chasing lookup because the lookup result drives subsequent processing in
> the data plane.  For example, a table has two entries (entry1 and entry2).
> On table lookup, if entry1 is hit, the result of lookup includes action1
> which is invoked.  An action is a C function.  If entry2 is hit, action2 is
> invoked.
>

Maybe we need to clarify some terms here.  What does "lookup" mean to you?
What is the lookup key,
and what is the result of the lookup?  Are you are talking about matching a
packet (mask and value match)?
If so, a Classifier session is used for that purpose.  Within the session
entry, actions are specified.  You can
have a node-handoff to an existing graph node, or opaque handoff, or
handoff to your own node for processing.

An alternative I am thinking is to change VPP code to support P4 better –
> support explicit table lookup and running user-supplied actions.   VPP does
> run actions but they are pre-defined.
>

I don't know what you mean by "user supplied actions", so you're on your
own there.

HTH,
jdl

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

[Jon Loeliger via lists.fd.io]

On Fri, Sep 25, 2020 at 4:35 PM hemant via lists.fd.io  wrote:

> In the classify API mentioned in the subject of this email, I could use an
> example with tables to understand table_index, next_table_index, and
> miss_next_index.  I know VPP maintains an index for a table.
>
>
>
> Say, the tables are invoked in this order for this example:
>
>
>
> Ethernet-input, ip4-iput, pkt_filter4 (my new table), rewrite
>
>
>
> If table_index is that of pkt_filter4, I suppose, next_table_index is
> rewrite?  I am not sure what is miss_next_index which is invoked if
> pkt_filter4 incurs a miss.
>

Hemant.

The items you listed above are graph nodes.  They are not classifier table
indices.
I will grant you these are confusing names, everything is an index into
some table.

The classifier tables are chained via the next_table_index field.  After a
miss searching in one
table, the search continues in the next_table_index classifier table if it
is available.  If the
next_table_index does not exist, the packet is handed off to the graph node
given as miss_next_index.
If a lookup within a table hits, the "next_index" is the graph node that
will receive the packet.

Fair warning:  I _think_ this is how it works.  I've only just read through
this code recently myself. :-)

HTH,
jdl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17580): https://lists.fd.io/g/vpp-dev/message/17580
Mute This Topic: https://lists.fd.io/mt/77126788/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] table lookup api?

[Jon Loeliger via lists.fd.io]

On Mon, Sep 28, 2020 at 1:15 PM hemant via lists.fd.io  wrote:

> I have created a table in VPP using the vnet_classify_add_del_session()
> API.
>
>
>
> What API do I use to lookup this table?
>
>
>
> Thanks,
>
>
>
> Hemant
>

There is no API to do a Classifier table lookup.   When the table was
created via the API,
it's table_index was returned in the classify_add_del_table_reply field
new_table_index.
You should know why you created that table, so stash that new_table_index
somewhere
in your management data, perhaps in your own (name,table_index) hash table.

HTH,
jdl

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

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

[Jon Loeliger via lists.fd.io]

On Sat, May 16, 2020 at 10:02 AM Christian Hopps  wrote:

>
> I know we use the binary APIs, I believe Netgate does as well. I'm sure
> there are others too (might be good to collect a list of these folks if one
> doesn't exist yet).
>

Indeed, Netgate uses the binary APIs extensively.

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

View/Reply Online (#16437): https://lists.fd.io/g/vpp-dev/message/16437
Mute This Topic: https://lists.fd.io/mt/74228149/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 regarding ICMP NAT behavior

[Jon Loeliger via lists.fd.io]

On Thu, May 14, 2020 at 11:23 AM Jon Loeliger via lists.fd.io  wrote:

> Did the ICMP mapping open more than was expected or intended here?
>
> I chased this down in the code a bit, but I'm not sure what the _intent_
> is supposed to be.
> When "address only" is true (ie, both ports are 0), then the protocol
> appears not to be
> used in any of the NAT-entry lookups.  Is that somehow allowing UDP and
> TCP to slide
> through?
>
> Thanks,
> jdl
>

So, here is the same scenario using vppctl to set up the test case.

vpp# nat44 add static mapping icmp local 192.168.0.53 external outside
vpp# show nat44 static mappings
NAT44 static mappings:
 local 192.168.0.53 external 192.168.0.53 vrf 0
 local 192.168.0.53 external outside vrf -1

NO reference to ICMP in the output of "show nat44 static mappings"

Here is confirmation that the outside interface (192.168.0.53) is
permitting the inbound SSH session:

tcp00 192.168.0.53:22192.168.0.120:50445 ESTABLISHED -
Outside
tcp00 172.21.89.1:22 172.21.89.123:51289 ESTABLISHED -
Inside
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Question regarding ICMP NAT behavior

[Jon Loeliger via lists.fd.io]

Hi vpp-devers,

We have a report of an unexpected behavior when using a static NAT with
ICMP.
It appears that configuring an outside interface to allow ICMP also allows
forwarding
of all protocols as well.

If you start with, say, a blocked TCP on port 22 and an SNMP on port 161,
then
adding a NAT static map of ICMP on an inside-facing address of 192.16.0.53
for
an outside interface of TenGigabitEthernet6/0/0, then suddenly TCP/UDP are
accessible from the outside using SSH and SNMP.  (No, this isn't vppctl
syntax. :-))

(config)# nat static map icmp local 192.168.0.53 external outside
(config)# show nat static
Static Mappings

Proto Local IP Port External IP  Port Interface Twice NAT Out to
In Route Table
-     - -
- ---
  192.168.0.530 0.0.0.0 0   outside
  ipv4-VRF:0
  192.168.0.530 192.168.0.530
  ipv4-VRF:0

Did the ICMP mapping open more than was expected or intended here?

I chased this down in the code a bit, but I'm not sure what the _intent_ is
supposed to be.
When "address only" is true (ie, both ports are 0), then the protocol
appears not to be
used in any of the NAT-entry lookups.  Is that somehow allowing UDP and TCP
to slide
through?

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

View/Reply Online (#16389): https://lists.fd.io/g/vpp-dev/message/16389
Mute This Topic: https://lists.fd.io/mt/74208726/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] route lookup api

[Jon Loeliger via lists.fd.io]

Chris,

If you can shoot me the patch, as is, I will rebase and submit it?

jdl


On Mon, Apr 27, 2020 at 7:27 PM Dave Wallace  wrote:

> Gentle reminder that the VPP 20.05 API freeze is next Wed, May 6, 2020, so
> please don't delay to long if this is required for 20.05.
>
> Thanks,
> -daw- (wearing the friendly VPP release manager hat)
>
> On 4/27/2020 5:02 PM, Christian Hopps wrote:
>
> On Apr 27, 2020, at 11:44 AM, Jon Loeliger via lists.fd.io 
>   wrote:
>
>
>
> On Wed, Feb 19, 2020 at 4:47 AM Christian Hopps  
>  wrote:
>
>
> On Feb 19, 2020, at 2:02 AM, Neale Ranns via Lists.Fd.Io 
>   wrote:
>
>
> Hi Chris,
>
> Adding an API to dump a single route would be a welcome addition to the API.
>
> Ok, I'll do that then.
>
> Hey Chris,
>
> Did you ever get this API enhancement written?  If so, is there a Gerrit for 
> it?
>
> I have this written/tested, but it lives in my 19.08 (product) branch right 
> now. I might have near the end of the week to cherry pick it to master and 
> test it there.
>
> Thanks,
> Chris.
>
>
> Thanks,
> jdl
>
>
>
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16175): https://lists.fd.io/g/vpp-dev/message/16175
Mute This Topic: https://lists.fd.io/mt/71382541/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] route lookup api

[Jon Loeliger via lists.fd.io]

On Wed, Feb 19, 2020 at 4:47 AM Christian Hopps  wrote:

>
> > On Feb 19, 2020, at 2:02 AM, Neale Ranns via Lists.Fd.Io  cisco@lists.fd.io> wrote:
> >
> >
> > Hi Chris,
> >
> > Adding an API to dump a single route would be a welcome addition to the
> API.
>
> Ok, I'll do that then.


Hey Chris,

Did you ever get this API enhancement written?  If so, is there a Gerrit
for it?

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

View/Reply Online (#16161): https://lists.fd.io/g/vpp-dev/message/16161
Mute This Topic: https://lists.fd.io/mt/71382541/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] QinQ and dot1ad any

[Jon Loeliger via Lists.Fd.Io]

On Wed, Dec 18, 2019 at 2:38 PM John Lo (loj)  wrote:

> Hi Jon,
>
>
>
> You are right on both counts.  It is the combination of dot1q/ad-any and
> exact-match that we should reject.  It is also correct the check should be
> at lower level to reject the combination for both API and CLI.
>
>
>
> Regards,
>
> John
>

John,

A first-effort patch has been submitted here:
https://gerrit.fd.io/r/c/vpp/+/24077

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

View/Reply Online (#14927): https://lists.fd.io/g/vpp-dev/message/14927
Mute This Topic: https://lists.fd.io/mt/68757125/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] QinQ and dot1ad any

[Jon Loeliger via Lists.Fd.Io]

On Tue, Dec 17, 2019 at 8:13 AM John Lo (loj) via Lists.Fd.Io  wrote:

>
> Thus, sub-interface with "inner-dot1q any" is not an exact match
> sub-interface by definition since no match is present on inner tag.
>
> I suppose the CLI:
> >> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any
> exact-match
> should have been rejected as exact match cannot be supported on the
> sub-interface.  This is something we should ideally fix in the CLI to avoid
> any confusion with the meaning of exact match.
>
> Regards,
> John
>

Hi John,

I have two questions here.  First, a clarification on what combinations of
options
should be rejected.  Are you saying that the pair "inner-dot1q any"
should be rejected,
or are you saying the trio "inner-do1q any exact match" should be
rejected.  I suspect
you are meaning the latter.

Second, while rejecting it in the CLI would be nice, that would still
allow the configuration
via the API, right?  So it might be better to reject it one layer down so
it is caught by
both the CLI and the API.

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

View/Reply Online (#14921): https://lists.fd.io/g/vpp-dev/message/14921
Mute This Topic: https://lists.fd.io/mt/68757125/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] Ipv6 neighbor not getting discovered

[Jon Loeliger via Lists.Fd.Io]

On Tue, Dec 3, 2019 at 10:09 AM Rajith PR  wrote:

> Hello Team,
>
> During integration of our software with VPP 19.08 we have found that ipv6
> neighbor does not get discovered on first sw_if_index on which ipv6 is
> enabled.
>

Do you have a small test case available?


> Based on our understanding, "0" is a valid adjacency index. After changing 
> the code as below the problem seems to have been solved.
>
>   else
> {
>   adj_index0 = radv_info->mcast_adj_index;
>   *if (adj_index0 == ADJ_INDEX_INVALID )*
>
>
> *error0 = ICMP6_ERROR_DST_LOOKUP_MISS;else*
> {
>   next0 =
> is_dropped ? next0 :
> ICMP6_ROUTER_SOLICITATION_NEXT_REPLY_RW;
>   vnet_buffer (p0)->ip.adj_index[VLIB_TX] =
> adj_index0;
> }
> }
>
> Is this fix correct?
>
> I think this is correct.

> If yes, can this be fixed in the master branch please.
>
> Thanks,
>
> Rajith
>
>
HTH,
jdl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14769): https://lists.fd.io/g/vpp-dev/message/14769
Mute This Topic: https://lists.fd.io/mt/65768746/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] Requirements for DPDK pmd/feature testing in CSIT vpp-device-test jobs

[Jon Loeliger via Lists.Fd.Io]

On Thu, Nov 21, 2019 at 6:55 AM Vratko Polak -X (vrpolak - PANTHEON
TECHNOLOGIES at Cisco) via Lists.Fd.Io 
wrote:

> > a +2 triggers a pre-commit gate where VOM and the dist builds and the
> extended tests are run.
>
> > If everything passes, the change is merged, if not, the +2 is removed.
>
>
>
> +1 to that, but I highly doubt Gerrit supports such a workflow.
>
>
>
> Additional features we would like to have:
>
> ...
>
> + The gate job squashes multiple pending changes before testing
>
>   (to keep up with the high frequency of +2 without introducing long
> queues).
>

Please do not squash patches.


> Vratko.
>

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

View/Reply Online (#14658): https://lists.fd.io/g/vpp-dev/message/14658
Mute This Topic: https://lists.fd.io/mt/60208819/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] [VCL] hoststack app crash with invalid memfd segment address

[Jon Loeliger via Lists.Fd.Io]

On Thu, Nov 21, 2019 at 4:50 AM wanghanlin 
wrote:

> Hi Florin,
> I have applied the patch, and found some problems in my case.  I have not
> right to post it in gerrit, so I post here.
>

Why don't you register with Gerrit, like this:

https://wiki.fd.io/view/DEV/Setting_up_Gerrit

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

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

[vpp-dev] VLAN tag-rewrite questions

[Jon Loeliger via Lists.Fd.Io]

John, et al.,

The vppctl command "set interface l2 tag-rewrite" and the associated API
call "l2_interface_vlan_tag_rewrite" allow an interface to have an L2
tag-rewrite rule
applied or removed from an interface.  That interface is usually a subif,
but it
may also apply to a regular (ethernet) interface as well.

Back in April, we patched the interface code to properly return the
VLAN tag-rewrite vtr_op operation on normal interfaces as well as
subinterfaces:

commit fdea5c6a00b74971dbb1b7ec4e25839a871006ca
Author: Alexander Chernavin 
Date:   Fri Apr 26 10:43:09 2019 -0400

IF: return VTR attributes for all ifs in dump API

With this commit, VTR attributes are shown not only for
subinterfaces
but for all interfaces.

However, that functionality was lost when commit
053204ab039d34a990ff0e14c32ce3b294fcce0e
accidentally stepped on it.

I have submitted a new patch to restore that functionality, and have
added you to the patch reviewers.

This morning, however, I noticed that the same bug is present in the
VAT code as well, in the function vl_api_sw_interface_details_t_handler()
from src/vat/api_format.c, around line 1003 or so.  I will update my
patch to fix this code too.

In the meantime, I have a question regarding this behavior.  It seems there
is a general lack of understanding here, or perhaps, a very specific lack
of understanding on my part. :-)

All of the code, and all of the tests seem to behave as if the rewrites can
only operate on a sub-interface, and that the configuration can only be
displayed when printed with an associated bridge-domain.  I guess I don't
understand that.  Shouldn't we be able to have and to see the vlan
tag-rewrite
on a regular (ethernet) interface without it being in a bridge or being a
subif?

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

View/Reply Online (#14564): https://lists.fd.io/g/vpp-dev/message/14564
Mute This Topic: https://lists.fd.io/mt/53060174/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] A few MAP-T Clarifications

[Jon Loeliger via Lists.Fd.Io]

On Thu, Nov 7, 2019 at 7:23 AM Ole Troan  wrote:

> Dear Jon,
>
> I think were we left this last was a "shared TODO" list.
>

Yeah, sorry, I got tasked with something else for a bit...


> The MAP specific shallow virtual reassembly has been generalised, and
> moved to a separate component.
> SVR now runs in front of MAP, so MAP doesn't need to deal with reassembly
> itself. That simplifies that handling quite a bit.
>

We had several bugs against the MAP fragmentation handling.  Perhaps these
changes have fixed them?  We are about to pull and merge these changes, so
we will check again!

What do you see as gaps? Feel free to patch.
>

We have some outstanding bugs against MAP-E/T here:

1) MAP BR doesn't send ICMPv6 unreachable messages when a packet fails to
match a MAP domain
2) MAP-T BR can't translate IPv4 ICMP Echo Reply to IPv6
3) Pre-resolve ipv4|ipv6 function isn't working when MAP-T mode is used
4) TCP MSS value isn't applied to encapsulated packets when MAP-E mode is
used

Issues 1) and 2) are likely the same underlying problem.
Issue 3) is what started this thread last April.
Issue 4) is new-to-me.  Our bug log suggests that a VPP patch was made for
it by Vladimir Ratnikov.

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

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

[vpp-dev] FIB Route Sources

[Jon Loeliger via Lists.Fd.Io]

Neale,

We have a use case where we would like to be able to
determine a more-fine-grained reason for introducing routes
into the FIBs.  All the routes we introduce will come via some
API call, but on behalf of different sources.  Specifically, they
will come from a user-supplied static route, different routing
protocols (BGP, OSPF, etc).

What would you say to adding a few more enum entries into
the fib_source_t type?  We could then modify the
fib_api_route_add_del() to allow the API to state which
source should be used rather than just "API".

Thoughts?

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

View/Reply Online (#14534): https://lists.fd.io/g/vpp-dev/message/14534
Mute This Topic: https://lists.fd.io/mt/44489479/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] A few MAP-T Clarifications

[Jon Loeliger via Lists.Fd.Io]

Ole,

Waaay back in April, we had a small exchange here on the topic
of some MAP-T/E behavior.  Bottom line was some functionality
needed to be homogenized.   We wrote:

On Tue, Apr 16, 2019 at 2:35 AM Ole Troan  wrote:

> Hi Jon,
>
> Apologies for the delay in answering. Swapped out all my knowledge of MAP
> to disk. ;-)
>
> > We are working on some MAP-E and MAP-T testing, and we have
> > a few questions.  Some of the existing VPP documentation about
> > MAP-E and MAP-T is a bit loose.
> >
> > Should the use of a pre-resolved forwarding address be applicable
> > to both MAP-E and MAP-T?  Or is that only a MAP-E thing?  Specifically,
> > we see in the test/test_map.py test that it is only tested in the MAP-E
> case.
> > Is it missing from the MAP-T tests due to oversight, or is that
> technically correct?
>
> -E and -T has evolved a little differently, which accounts for the
> differences.
> Pre-resolved next-hops is applicable for both. Should we do a shared todo
> list for MAP items?
> Perhaps an epic JIRA?
>
> > The MAP-T test also "enables map" on both interfaces in that same file.
> > Is it required to do so?  For only MAP-T?
>
> I would think so. Isn’t one the IPv4 side and the other interface the IPv6
> side?
> In both cases packets are picked out from the IP feature path.
>
> > Finally, there is no test that introduces a rule.  I feel like I read
> somewhere
> > that MAP-T required at least one rule?  Or is some combination of PSID
> > and EA bits sufficient alone?
>
> Rules was developed for the LW46 1:1 case. As per subscriber rules as
> opposed to algorithmic mapping for many users within a domain.
> I think rules can be useful also in a MAP-T case. We should homogenize
> that.
>
> Patches welcome!
>
> Best regards,
> Ole


... and we're back!  Months pass, seasons change, and the code has,
what?, been fixed?  ignored? silently left to bit-rot?  Where are we today?

Any chance there has been progress here?

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

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

Re: [vpp-dev] VPP Interfaces from with (Docker) Containers?

[Jon Loeliger via Lists.Fd.Io]

On Mon, Oct 7, 2019 at 2:21 PM Damjan Marion  wrote:

>
> BTW I strongly suggest that you don't use uio_pci_generic.
>

Last we looked, any integration with QAT was only available using the
uio_pci_generic driver.
Will QAT work with the vfio-pci driver these days?  If so, awesome!  If
not, that will definitely
need to be fixed

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

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

Re: [vpp-dev] VPP Interfaces from with (Docker) Containers?

[Jon Loeliger via Lists.Fd.Io]

On Mon, Oct 7, 2019 at 11:04 AM Benoit Ganne (bganne) 
wrote:

> > In each of the cases above where I said "still doesn't work", when the
> > /dev/uio* is present, it is found.  However, it then leads to this
> > error as reported by vppctl's "show log" command:
>
> I did not check uio. I do use vpp in containers with dpdk for development,
> but:
>  - I use privileged containers for this (docker run --privileged or
> similar)
>  - I use vfio-pci instead of uio
> So you may want to try that.
>

Hi Ben,

So, I finally figured it out.  I stepped back and just installed VPP
directly on the
system (not in a container), and saw that there were some packaging and DPDK
install issues that were being masked by the container build.  I fixed all
that,
and now the container is able to support VPP and DPDK finding the
interfaces!

Thanks for your help here!

jdl

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

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

Re: [vpp-dev] VPP Interfaces from with (Docker) Containers?

[Jon Loeliger via Lists.Fd.Io]

On Fri, Oct 4, 2019 at 3:33 AM Benoit Ganne (bganne) 
wrote:

> Hi,
>
> Yes containers usually do not update /dev after creation, so any device
> that shows up dynamically afterwards won't be available by default. Note
> this is not specific to VPP.


OK cool, that is what it was looking like...

To access PCI devices from userspaces you'll need access to either
> /dev/vfio/* or /dev/uio* device nodes depending of the driver.
>

Yeah, DPDK is looking for /dev/uio*...


> You have several options:
>  1) make sure the device showed up before starting the container so that
> they will be populated
>

I have tried this, and it doesn't work.


>  2) create you container using '-v /dev:/dev' to bind mount /dev: every
> changes in host /dev is visible to container
>

Also, does not work.


>  3) use mknod to make the device nodes in the container
>

This, I expected to work, but it does not.


>  4) run udev in your container
>

Could you clarify a bit what you mean by this?  Or how to set that up?
udev is, of course, already running on the host system.

In each of the cases above where I said "still doesn't work", when the
/dev/uio* is
present, it is found.  However, it then leads to this error as reported by
vppctl's
"show log" command:

2019/10/04 21:23:48:566 notice dpdk   EAL: PCI device :06:00.1
on NUMA socket -1
2019/10/04 21:23:48:566 notice dpdk   EAL:   Invalid NUMA socket,
default to 0
2019/10/04 21:23:48:566 notice dpdk   EAL:   probe driver:
8086:15e4 net_ixgbe

I've not yet chased that down.  Any chance there is more direct knowledge
about it?

I suspect the real problem is that there is some form of namespace problem
that
is preventing the device from being used (seen?) properly.  Does the /dev
entry
belong to a specific namespace?  And if VPP/DPDK doesn't actually make the
device
(via the driver call), does it end up in the wrong namespace still?

Best
> ben
>

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

View/Reply Online (#14134): https://lists.fd.io/g/vpp-dev/message/14134
Mute This Topic: https://lists.fd.io/mt/34386250/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 Interfaces from with (Docker) Containers?

[Jon Loeliger via Lists.Fd.Io]

Folks, and maybe Damjan in particular?,

I am trying to run VPP from within a Docker container using
the Ligato framework for head-banging.  The head-banging part
is working.  The VPP interface binding part, not so much.

>From what I can tell, VPP sees the PCI devices, but then grouses
that the /dev/uio[012] devices are not available.  Indeed, they are
not visible from the container, but they did get created on the host!

When starting a 'docker container run', there is a '--device=' option
that maps host devices into the container, but this isn't useful as the
devices don't exist before the container (and VPP) get started.

Seems to me that VPP (DPDK?) needs to maybe make those devices
within the (net?) namespace of the creating process?  Or maybe
something more basic?  Insidious?  Clever?

Any insight?

Thanks,
jdl

PS -- And yeah, no, I'm not sure how the Ligato folks get this to work.
This part of the puzzle is not mentioned in any docs that I've
found,
so it is a bit of a puzzlement still.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Jon Loeliger via Lists.Fd.Io]

On Mon, Jun 17, 2019 at 3:43 PM Damjan Marion  wrote:

>
> On 17 Jun 2019, at 22:41, Jon Loeliger  wrote:
>
> On Mon, Jun 17, 2019 at 3:33 PM Damjan Marion  wrote:
>
>>
>> I tried to be as much descriptive as possible in those messages, but
>> looks like I failed :(
>>
>
> Damjan,
>
> No problem.  I am working on some improvements.
>
> For example, fixing these problems:
>
> $ echo "Consolidate IPv6 link-local-address functions." |  sed -e
> 's/\(.*\):.*/\1/'
> Consolidate IPv6 link-local-address functions.
>
> $ echo "foo: bar: baz: Consolidate IPv6 link-local-address functions." |
>  sed -e 's/\(.*\):.*/\1/'
> foo: bar: baz
>
>
> Your commit message needs to be:
>
> foo bar baz: consolidate...
>

Damjan,

I think there will be unexpected complications with this approach.
Consider this:

$ echo "docs: fix http:/foo.example.com:8080/fred use." |  sed -e
's/\(.*\):.*/\1/'
docs: fix http:/foo.example.com

That won't match "docs:", nor any other valid I: word in any case where
there is an
additional colon later in the subject line.  It will also allow false
positives like this
subject:  "whanged on ip stuff: it was messed up".

Historically, these things have been keywords individually terminated by a
colon, as
I gave in my example.  Once the collection of keywords is gathered, strip
the trailing
colons for validity comparisons.

Just a thought.

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

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

[Jon Loeliger via Lists.Fd.Io]

On Mon, Jun 17, 2019 at 3:33 PM Damjan Marion  wrote:

>
> I tried to be as much descriptive as possible in those messages, but looks
> like I failed :(
>

Damjan,

No problem.  I am working on some improvements.

For example, fixing these problems:

$ echo "Consolidate IPv6 link-local-address functions." |  sed -e
's/\(.*\):.*/\1/'
Consolidate IPv6 link-local-address functions.

$ echo "foo: bar: baz: Consolidate IPv6 link-local-address functions." |
 sed -e 's/\(.*\):.*/\1/'
foo: bar: baz

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

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

[Jon Loeliger via Lists.Fd.Io]

And now this:

=== ERROR ===

Unknown feature 'Consolidate' in commit 'Subject:' line.
Feature must exist in MAINTAINERS file. If this commit intruduces
new feature, then this commit must add new entry into the
MAINTAINERS file.
=== ERROR ===

Does it just check the first word on the subject line regardless?
What else is being checked?  Poorly?
Does it _have_ to match a MAINTAINER I: word?

Where is this script?  Rhetorical.  It is here:
extras/scripts/check_commit_msg.sh

Now I at least know what I am up against.

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

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

[vpp-dev] Triggering a Verify Job?

[Jon Loeliger via Lists.Fd.Io]

Folks,

I am failing to trigger a "verify job" using the Review keyword "recheck"
on one of my patches.

Can someone remind me how to clear up my dumbness?

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

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

[vpp-dev] Commit Subjects

[Jon Loeliger via Lists.Fd.Io]

Folks,

I received this during a build of a patch I submitted:

=== ERROR ===
Unknown feature 'IPv6' in commit 'Subject:' line.
Feature must exist in MAINTAINERS file. If this commit intruduces
new feature, then this commit must add new entry into the
MAINTAINERS file.
=== ERROR ===

Can we modify the scripts/check-something to verify this before
it is submitted?

Can we fix the spelling error in the message?

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

View/Reply Online (#13301): https://lists.fd.io/g/vpp-dev/message/13301
Mute This Topic: https://lists.fd.io/mt/32096793/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] IPv6 Link-local Address Questions

[Jon Loeliger via Lists.Fd.Io]

On Thu, Jun 13, 2019 at 11:21 AM Ole Troan  wrote:

> Hi Jon,
>
> Thanks for bringing up my favorite topic!
>

Happy to step on those land mines! :-)

Uh, is that "Duplicate but slightly wrong functions", "bit-byte-numbering
issues",
or "link-local addressing"? :-)


> > I am happy to submit a patch to fix this situation, but I'd like to make
> sure we get it right. :-)
> >
> > Here's what I think we should do:
> > - Remove the function ip6_link_local_address_from_ethernet_address()
> as it
> >   contains the incorrect bit, (1 << 6).
> > - Replace the one use of that function with a call to
>
> Yes, please!
>  ip6_link_local_address_from_ethernet_mac_address() instead.
> > - Answer the bit-wise XOR vs OR question ...?
>
> XOR is correct.
>

Excellent.  Patch in a moment.  Local testing...


> Cheers
>
Ole
>

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

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

[vpp-dev] IPv6 Link-local Address Questions

[Jon Loeliger via Lists.Fd.Io]

Folks,

I have stumbled across two functions that purport to construct a
link-local IPv6 address from a MAC address.  A laudable goal,
but the details need some review.

One function can be found in src/vnet/ip/ip6.h:

always_inline void
ip6_link_local_address_from_ethernet_mac_address (ip6_address_t * ip,
  u8 * mac)
{
  ip->as_u64[0] = clib_host_to_net_u64 (0xFE80ULL);
  /* Invert the "u" bit */
  ip->as_u8[8] = mac[0] ^ (1 << 1);
  ip->as_u8[9] = mac[1];
  ip->as_u8[10] = mac[2];
  ip->as_u8[11] = 0xFF;
  ip->as_u8[12] = 0xFE;
  ip->as_u8[13] = mac[3];
  ip->as_u8[14] = mac[4];
  ip->as_u8[15] = mac[5];
}

I draw your attention to the assignment to ip->as_u8[8], where bit 0x02 is
XOR'ed in.

The second function is found in src/vnet/ip/ip6_packet.h:

always_inline void
ip6_link_local_address_from_ethernet_address (ip6_address_t * a,
  const u8 * ethernet_address)
{
  a->as_u64[0] = a->as_u64[1] = 0;
  a->as_u16[0] = clib_host_to_net_u16 (0xfe80);
  /* Always set locally administered bit (6). */
  a->as_u8[0x8] = ethernet_address[0] | (1 << 6);
  a->as_u8[0x9] = ethernet_address[1];
  a->as_u8[0xa] = ethernet_address[2];
  a->as_u8[0xb] = 0xff;
  a->as_u8[0xc] = 0xfe;
  a->as_u8[0xd] = ethernet_address[3];
  a->as_u8[0xe] = ethernet_address[4];
  a->as_u8[0xf] = ethernet_address[5];
}

Here, I draw your attention to the similar assignment to a->as_u8[8] where
bit 0x40 is OR'ed in.

I will grant you that confusion exists in the literature.  Let's dispense
with
"counting from 0" and "counting from 1", and guessing if the displayed bits
are ordered Left to Right as 0 to 7, or 7 to 0.   Let's talk powers of 2
instead.

My understanding, though possibly wrong, is that 2^1 of byte 8 is the
question.
So I believe the (1 << 6) is wrong.  So we'll talk about 0x02, which I
believe is correct.

Now, should the bit be set, or XOR'ed?  There are arguments for both cases,
so I
do not know which is correct and desired here.  Specifically, given a MAC
address,
does that 0x02 bit need to be inverted to maintain its Global/Local status
as it is
copied to the IPv6 address?  Do we even want to maintain its G/L status?
Or do
we want to force it to be locally administered by slamming the bit to 1?

I am happy to submit a patch to fix this situation, but I'd like to make
sure we get it right. :-)

Here's what I think we should do:
- Remove the function ip6_link_local_address_from_ethernet_address() as
it
  contains the incorrect bit, (1 << 6).
- Replace the one use of that function with a call to
  ip6_link_local_address_from_ethernet_mac_address() instead.
- Answer the bit-wise XOR vs OR question ...?

Other suggestions or advice?

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

View/Reply Online (#13280): https://lists.fd.io/g/vpp-dev/message/13280
Mute This Topic: https://lists.fd.io/mt/32054012/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] Weird Error Number

[Jon Loeliger via Lists.Fd.Io]

On Wed, May 8, 2019 at 7:24 AM Ole Troan  wrote:

> Hi Jon,
>
> > Can anyone shed some light here?
>
> I guess the purpose of a positive value is to indicate that you can try
> again with the same arguments and get a different response,
> as opposed to a negative value.
>
> I would be in favour of removing that error from api_errno.h.
> Especially for these corner cases I'd much rather want a documented
> separate error number space for the module / message.
>
> Best regards,
> Ole
>

Hi Ole,

I will submit a patch to remove the positive error number
and the corresponding use of it.

And remove the entire dead function as well...?

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

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

[vpp-dev] Weird Error Number

[Jon Loeliger]

Folks,

So I was reading src/vnet/api_errno.h, as you do, and I noticed
this weird line:

_(IN_PROGRESS, 10, "Operation in progress")
 \

That's right, an error number that is positive.  It just doesn't sound
right...
And I don't think it is simply missing a negative sign as there is also
this line:

_(INVALID_SW_IF_INDEX_2, -10, "Invalid sw_if_index #2")
 \

So, digging some:

jdl $ git grep VNET_API_ERROR_IN_PROGRESS
src/plugins/nat/nat_ha.c:return VNET_API_ERROR_IN_PROGRESS;

Which is here:

int
nat44_ha_resync (u32 client_index, u32 pid,
 nat_ha_resync_event_cb_t event_callback)
{
  nat_ha_main_t *ha = _ha_main;
  snat_main_t *sm = _main;
  snat_session_t *ses;
  snat_main_per_thread_data_t *tsm;

  if (ha->in_resync)
return VNET_API_ERROR_IN_PROGRESS;

But then this too:

jdl $ git grep nat44_ha_resync
src/plugins/nat/nat_ha.c:nat44_ha_resync (u32 client_index, u32 pid,

So it appears that it may not even be being used...?

Can anyone shed some light here?

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

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

[vpp-dev] A few MAP-T Clarifications

[Jon Loeliger]

Good Morning,

We are working on some MAP-E and MAP-T testing, and we have
a few questions.  Some of the existing VPP documentation about
MAP-E and MAP-T is a bit loose.

Should the use of a pre-resolved forwarding address be applicable
to both MAP-E and MAP-T?  Or is that only a MAP-E thing?  Specifically,
we see in the test/test_map.py test that it is only tested in the MAP-E
case.
Is it missing from the MAP-T tests due to oversight, or is that technically
correct?

The MAP-T test also "enables map" on both interfaces in that same file.
Is it required to do so?  For only MAP-T?

Finally, there is no test that introduces a rule.  I feel like I read
somewhere
that MAP-T required at least one rule?  Or is some combination of PSID
and EA bits sufficient alone?

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

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

[vpp-dev] Adding User-assigned IDs to VPP objects

[Jon Loeliger]

Ole and Neale,

You have both asked essentially the same question in a code review:

Neale:
   what's the use case for these tag fields?
if i's to correlate VPP objects with user-assigned IDs, are there any
object in VPP
that would not require a tag?
Ole:
Would it be possible to come up with a scheme were you didn't allocate the
space
for the tag strings unless they were used by a domain? I have seen use
cases with millions of domains. 64 byte * 2M is still a bit of memory.
Otherwise I'm perfectly fine with the idea though. Although the address to
tag mapping
could happily live outside of VPP too, right?

To summarize, we have effectively added some from of user-assigned ID to
every create-able
object in VPP that we have placed under management. There are basically 3
approaches
we have taken:
1) Add a u32 "user-ID" to the objects's main per-instance structure.
2) Add a string "tag" field to the object's main per-instance structure.
3) Allow the user to supply a "user ID".
   If that is supplied and it is available, use it as the instance ID.
   If it is not supplied, VPP picks a free one (from pool).

In any case, there is usually still a distinction between the "user ID" and
the "device instance".
Except for case 3), VPP really only stores and regurgitates the user ID (on
create and dump,
respectively). For 3) some more fiddling (in-use bit-vector) is necessary.

An example of case 3) is found in the bridge management code, here:
src/vnet/l2/l2_bd.c
The primary implementation are the functions bd_find_index()
and bd_add_bd_index()
They are used in bd_add_del() and l2bd_init().

I point this out, as I am wondering if you would be willing to use this
approach with
the MAP domain IDs too.  They would still be allocated using the same pool,
of course, but this would allow the user to pick a free pool index and thus
use only
one name (ID), and not have to manage two IDs.

If you do not want to take this approach, I am happy to add a hash table
mapping the existing map domain indices to either a user-supplied u32
or string name.  (This approach incurs essentially no extra space when
user-supplied names or u32 IDs are not supplied.)

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

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

[vpp-dev] Publishing IPSec Header Files

[Jon Loeliger]

Yo people,

Be that the vnet/ipsec/ipsec.h include file now chumming up
with the files:

#include 
#include 
#include 
#include 
#include 

all them gotsta either be published to /usr/include/vnet/ipsec as well,
or days gotsta not be included at all.

Seems like we's been here 'fore, man.

Wants me ta push a patch so's that they get published during an
install, or remove 'em and maybe include them in some .c files
where they's needed more?

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

View/Reply Online (#12318): https://lists.fd.io/g/vpp-dev/message/12318
Mute This Topic: https://lists.fd.io/mt/29990503/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] VLAN tag-rewrite question

[Jon Loeliger]

On Wed, Feb 13, 2019 at 11:20 AM Damjan Marion  wrote:

> On 13 Feb 2019, at 09:17, Jon Loeliger  wrote:
>
> VPPers,
>
> Is it intended that VPP supports placing VLAN tag rewrite rules on any
> interface?
>
> It should work with all ethernet interfaces including the virtual ones
>
> Damjan
>

Damjan,

Awesome!  Thanks for the quick reply!

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

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

[vpp-dev] VLAN tag-rewrite question

[Jon Loeliger]

VPPers,

Is it intended that VPP supports placing VLAN tag rewrite rules on any
interface?

The "Create ACCESS Ports" example on this page:
https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP
shows it happening on a virtual interface:
set interface l2 tag-rewrite VirtualEthernet0/0/2 push dot1q 200

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

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

[vpp-dev] An 'ip route' question

[Jon Loeliger]

Neale,

I have a question about the API field 'next_hop_table_id' within the
API call ip_add_del_route.  (There isn't a doc string for this field in
the API file, so guessing a bit.)  Is this field the same field for both
the CLI options 'next-hop-table' and 'ip4-lookup-in-table'?  Is there
a conceptual difference between these two CLI options, or are they
just different words for setting the same API field?  Is this merely
a mechanism for specifying the IPv[46] proto when an IP address
is not available to specify the proto?  (Also, note, CLI keyword
'lookup-in-vrf' as well.)

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

View/Reply Online (#11857): https://lists.fd.io/g/vpp-dev/message/11857
Mute This Topic: https://lists.fd.io/mt/28965063/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 duplicate nodes in the graph

[Jon Loeliger]

[ Just reposting as it was likely missed in the Holiday Extravaganza. --jdl
]

On Fri, Dec 28, 2018 at 9:21 AM Jon Loeliger  wrote:

> Folks,
>
> Is there a valid use for duplicate nodes in the node graph?
> Specifically, if I type this command three times:
>
> vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0
> vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0
> vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0
>
> I end up with duplicate ip4-vxlan-nodes:
>
> vpp# show interface features TenGigabitEthernet6/0/0
> [ ...]
> ip4-unicast:
>   ip4-not-enabled
>   ip4-vxlan-bypass
>   ip4-vxlan-bypass
>   ip4-vxlan-bypass
>
> In this case, I don't think it makes sense, and I think we should detect
> the presence of the node and disallow multiple additions.
>
> If that is true for this case, but NOT true for other cases, we might
> entertain
> a flag (per interface per family) in the
> function vnet_int_vxlan_bypass_mode()
> to record its addition and prevent subsequent re-additions.
>
> On the other hand, if duplicate nodes is a Bad Thing for the whole graph,
> perhaps the function vnet_feature_enable_disable() itself should be able
> to detect and prevent duplicates?
>
> Thoughts?
> jdl
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] VPP Failing (all?) Verify Jobs

[Jon Loeliger]

On Fri, Dec 28, 2018 at 9:25 AM Paul Vinciguerra 
wrote:

> Hi Jon,
>
> I opened a ticket (#66166) with the helpdesk on 12/25.
>

Ah, excellent.  Thanks!


> "Starting Dec. 14, 2018 through Jan. 1, 2019 the Linux Foundation will be
> operating with reduced staff in observance of our office closure.
> Responses to inbound support requests will be delayed, or otherwise
> addressed after Jan. 2, 2019."
>
> Please be patient.
>

Of course!

I just wasn't sure if "just rebase it" meant the root cause would hit the
floor or not.
With the ticket you opened, it's all good!

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

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

[vpp-dev] Question about duplicate nodes in the graph

[Jon Loeliger]

Folks,

Is there a valid use for duplicate nodes in the node graph?
Specifically, if I type this command three times:

vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0
vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0
vpp# set interface ip vxlan-bypass TenGigabitEthernet6/0/0

I end up with duplicate ip4-vxlan-nodes:

vpp# show interface features TenGigabitEthernet6/0/0
[ ...]
ip4-unicast:
  ip4-not-enabled
  ip4-vxlan-bypass
  ip4-vxlan-bypass
  ip4-vxlan-bypass

In this case, I don't think it makes sense, and I think we should detect
the presence of the node and disallow multiple additions.

If that is true for this case, but NOT true for other cases, we might
entertain
a flag (per interface per family) in the
function vnet_int_vxlan_bypass_mode()
to record its addition and prevent subsequent re-additions.

On the other hand, if duplicate nodes is a Bad Thing for the whole graph,
perhaps the function vnet_feature_enable_disable() itself should be able
to detect and prevent duplicates?

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

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

Re: [vpp-dev] VPP Failing (all?) Verify Jobs

[Jon Loeliger]

On Thu, Dec 27, 2018 at 1:11 PM Florin Coras  wrote:

> Paul came up with a better fix [1]. Rebasing of the patches should solve
> the verify problems now.
>
> Florin
>

Hi Florin,

While that worked enough to verify my patch, it seems like a temporary
solution.
Is there a proper longer term fix here?

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

View/Reply Online (#11786): https://lists.fd.io/g/vpp-dev/message/11786
Mute This Topic: https://lists.fd.io/mt/28866309/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 Failing (all?) Verify Jobs

[Jon Loeliger]

Folks,

It looks like VPP is failing (all?) verify jobs as it is unable to build
some variant.  Looks like a failed 'make install-dep' is wedging on
a Boost lib install.  (Build 9/9.)

Any insight here?

Thanks,
jdl


Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64
conflicts with namespace:otherproviders(libboost_headers-devel)
provided by libboost_headers-devel-1.69.0-lp150.1.1.noarch
Problem: libboost_thread1_68_0-devel-1.68.0-lp150.243.1.x86_64
conflicts with namespace:otherproviders(libboost_thread-devel)
provided by libboost_thread-devel-1.69.0-lp150.1.1.noarch

Problem: libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64
conflicts with namespace:otherproviders(libboost_headers-devel)
provided by libboost_headers-devel-1.69.0-lp150.1.1.noarch
 Solution 1: Following actions will be done:
  deinstallation of libboost_headers1_68_0-devel-1.68.0-lp150.243.1.x86_64
  deinstallation of libboost_chrono1_68_0-devel-1.68.0-lp150.243.1.x86_64
  deinstallation of libboost_date_time1_68_0-devel-1.68.0-lp150.243.1.x86_64
 Solution 2: do not install libboost_headers-devel-1.69.0-lp150.1.1.noarch

Choose from above solutions by number or skip, retry or cancel
[1/2/s/r/c] (c): c
make: *** [Makefile:316: install-dep] Error 4
Build step 'Execute shell' marked build as failure
$ ssh-agent -k
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 63 killed;
[ssh-agent] Stopped.
Skipped archiving because build is not successful
[PostBuildScript] - Executing post build scripts.
[vpp-verify-master-osleap15] $ /bin/bash /tmp/jenkins2611708312337033426.sh
Build logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269;>https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-osleap15/5269
uname -a:
 Linux f4f9bd3f69b6 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27
10:45:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11777): https://lists.fd.io/g/vpp-dev/message/11777
Mute This Topic: https://lists.fd.io/mt/28866309/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] MAP-E/MAP-T Futures?

[Jon Loeliger]

On Mon, Dec 17, 2018 at 5:50 AM Ole Troan  wrote:

> Hi Jon,
>
> > Is it your intention to re-factor the changes in
> > https://gerrit.fd.io/r/14247
> > to remove the FIB DPO and instead use an input feature?
>
> Yes, that was the plan.
> Of course we could keep the DPO code in there, and even make it a
> configuration knob which one to choose.
>

Ole,

I have a patch that adds just the new API calls from 14247, but doesn't
address
any of the direct DPO/input-feature changes yet.  I'm not certain about
those changes, nor how they would interact if both choices are made
available.
I could easily add the 14247 changes that add the lpm pieces, but I'm not
sure how they would tie-in with some of the other changes there.

I will post my patch as-is, and we can go from there.

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

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

[vpp-dev] MAP-E/MAP-T Futures?

[Jon Loeliger]

Ole,

Is it your intention to re-factor the changes in
https://gerrit.fd.io/r/14247
to remove the FIB DPO and instead use an input feature?

If so, it seems that having separated the API changes for
more precise types (ip4_address_t, etc) into its own change
will have simplified this (14247) patch and removed the
merge conflicts it was having.

Would you like help re-framing that change?

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

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

Re: [vpp-dev] VPP API language changes

[Jon Loeliger]

On Wed, Dec 5, 2018 at 6:04 AM Ole Troan  wrote:

> All,
>

Hi Ole,


> Here is an update on API progress.
>
> In the long process of making types in the API language more explicit I
> have a few changes merged and a few in the pipeline:
>

Hooray!


> - Type aliases. Previously any new user defined type had to be a
> structure. With type aliasing one can do
>   e.g.
>  typedef u32 interface_index
>  instead of:
>  typedef {
> u32 index;
>  } interface_index;
>
> This is merged in 53fffa1d
>
> I have a similar change for the relatively new ip4_address and ip6_address
> types, so instead of:
> typedef {
>   u32 address[4];
> } ip4_address;
>
> That is now: typedef u32 ip4_address[4];
>

And we mean s/u32/u8/ here, right? :-)


> I will try to update the API definitions with new type as I get the
> chance. bool and type aliases are backwards compatible (in that they
> require no change on the VPP side).
>

[ ... ]

Any other changes you’d like in the API language?
>

I noticed that we had f64, but not f32 the other day.  Is that by accident
or choice?
Related, it might be nice to have the clib_host_to_net_f{32,64}() functions
too?
(We are apparently doing those as clib_host_to_net_u64() and casting them
to f64 now.)

 And please let me know if you have comments on the above.
>
> Cheers,
> Ole
>

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

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

[vpp-dev] Some MAP-E/MAP-T API Questions

[Jon Loeliger]

Hi!

I have a few questions in the MAP-E/MAP-T area.

First the easy one:

In the src/plugin/map/map.h file, there is a #include .
That works fine in the source tree and the source-tree-based builds.
However, once installed on a system where out-of-tree builds take place,
It makes for an odd system-level include path because the "vpp_plugins"
piece
is missing.  Can we change that to '#include "?

And second, are there plans somewhere already in-motion to add an API
interface to the MAP-E/T configuration parameters?  They are already
available and configurable by the vppctl CLI, but not via the API.  Would
anyone be interested in a patch to refactor that parameter handling to allow
API access to those parameters too?

Finally, are there any known issues/bugs in the MAP-E/MAP-T packet-handling?

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

View/Reply Online (#11318): https://lists.fd.io/g/vpp-dev/message/11318
Mute This Topic: https://lists.fd.io/mt/28244962/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] depreciation of old tun/tap code

[Jon Loeliger]

On Fri, Sep 14, 2018 at 6:09 AM Damjan Marion via Lists.Fd.Io  wrote:

>
> Folks,
>
> Long time ago we discussed that we will deprecate old tun / tap code
> (vnet/unix/tuntap.[ch] and vnet/unix/tapcli.[ch])
> in favour of new one (src/vnet/devices/tap/).
>
> Now, we have new code for a long time, so wonder if there is still any
> good reason to keep old ones?
>

Damjan,

As far as I am concerned, it is fine to remove the old tun/tap code!

Will there be any effort to rename the so-called "V2" API names?
Or will they be left as-is with the "v2" in them?

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

View/Reply Online (#10504): https://lists.fd.io/g/vpp-dev/message/10504
Mute This Topic: https://lists.fd.io/mt/25672883/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] Endless NAT Questions

[Jon Loeliger]

On Wed, Aug 22, 2018 at 3:31 AM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Jon,
>
>
>
> I’ve updated nat_show_config_reply https://gerrit.fd.io/r/#/c/14411/,
> hope it is all here now
>
>
>
> Matus
>

Awesome!  I have +1'ed it!

Thank you!
jdl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10255): https://lists.fd.io/g/vpp-dev/message/10255
Mute This Topic: https://lists.fd.io/mt/24537787/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] NAT Fragment Reassembly

[Jon Loeliger]

On Thu, Aug 16, 2018 at 12:39 AM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Max_frag value is applied when fragments arrived out of order
>

Ahhh  That wasn't clear... But I see...


> (non-initial fragments arrive before first fragment which contains L4
> header), fragments are stored and waiting for first fragment (max_frag is
> limit for number of stored fragments). Fragments are dropped in
> nat44-in2out-reass or nat44-out2in-reass node. Whether fragments are
> dropped depends on order. All fragments should be dropped when max_frag is
> 1 and 2 non-initial fragments are received before first fragment. After a
> brief look into the code I see that this is not current behaviour and
> dropped is only second fragment so I think some improvements should be
> done in the future.
>

Would you like a bug report to keep track of that?


> Matus
>

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

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

[vpp-dev] Endless NAT Questions

[Jon Loeliger]

Matus,

Should the nat_show_config_reply structure be augmented
to have the (newer) fields added to it?

I'm thinking specifically about:
- the nat64_* values
- the dpo selection,
- the dslite values,
- the endpoint-dependent indication.

Also, it looks like "deterministic" and "endpoint-dependent" are
mutually exclusive.   Is that correct?

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

View/Reply Online (#10176): https://lists.fd.io/g/vpp-dev/message/10176
Mute This Topic: https://lists.fd.io/mt/24537787/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] NAT Fragment Reassembly

[Jon Loeliger]

On Wed, Aug 15, 2018 at 8:50 AM, Jon Loeliger  wrote:

> On Wed, Aug 15, 2018 at 12:49 AM, Matus Fabian -X (matfabia - PANTHEON
> TECHNOLOGIES at Cisco)  wrote:
>
>> Hi Jon,
>>
>>
>>
>> NAT plugin does virtual fragment reassembly – it enables to translate
>> non-initial fragments without L4 header otherwise NAT is unable to gather
>> port information from the non-initial fragment, packet is still broken into
>> several fragments after NAT translation.
>>
>>
>>
>> Matus
>>
>
> Thanks, Matus!
>
> I'm trying to understand how part of the NAT virtual reassembly works
> still.
> When and how does the drop_frag count come into play?  For example,
> if an original packet was broken into 3 fragments, and drop_frag was 1 or
> 2,
>

Naturally, I meant the "max_frag" values here.


> should all three fragments get dropped?  And are they dropped on ingress
> or egress?
>
> Is there a packet trace flow where I can see them being dropped?  I ask
> because it looks to me like these fragments are only sometimes dropped
> when the drop_frag value is exceeded, and it also requires the
>

And "max_frag" there too.


> ip_reassembly_enable_disable to be "on" too.
>
> I've been doing a "trace add dpdk-input 500", sending my example packets
> that need fragmentation, NAT-ing them, and then filtering the trace buffer.
> What is the right node to use in the "filter" here?
>
> Thanks,
> jdl
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10169): https://lists.fd.io/g/vpp-dev/message/10169
Mute This Topic: https://lists.fd.io/mt/24529319/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] NAT Fragment Reassembly

[Jon Loeliger]

On Wed, Aug 15, 2018 at 2:30 AM, Ole Troan  wrote:

> Jon,
>
> Thanks for bringing this up. In addition to Matus’ answer.
>

Hi Ole,

Thanks!


> There is a distinction to be made between forwarding and terminating
> traffic.
> And there is a nice grey middle ground between the two.
>
> Some features does forwarding on the transport header, like NAT, MAP-E,
> MAP-T and so on, those do not require reassembling the fragment chain, and
> do forward fragments in flights, aka virtual reassembly.
>

Right.


> Tunnels with  outer fragmentation require full reassembly (the packets are
> addresses to the node itself), before forwarding.
>
> But you could also argue that there are features like ACL, firewalls,
> legal intercept whatnot that would benefit from doing a full reassembly
> while forwarding.
>
> a) Virtual reassembly
> b) Full reassembly for terminating traffic (for-us / host)
> c) Full reassembly for forwarding traffic for specific features requiring
> that
>
> From a quick glance it seems like the current reassembly feature is doing
> c. And doing it without any level of granularity.
> Meaning that if you need outer reassembly for an IP in IP tunnel, you’d
> suddenly also reassemble all IP traffic.


And GRE?


> Which is unwanted and costly.
> That should be easy to fix. Klement?
>

I've not gotten to any of the IP-in-IP-like tunneling in my examples yet,
so that is a future problem. :-)  But hey, if we can fix it before we get
to it,
that always works! :-)



> So you are right if you combine the current reassembly (c) with NAT, NAT
> does not deal with the fragments.


So how does NAT's fragmentation handle the parameters of the
API_NAT_SET_REASS API call?  Specifically, the max_frag value?
It has to track all the fragments of one (original) packet and then does
it drop all the fragments if it exceeds the max_frag value?


> But at a much higher cost than virtual reassembly of course. I propose we
> move default reassembly to b instead of c, and that it’s only done in the c
> case for features that require it.
>
> Cheers,
> Ole


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

View/Reply Online (#10168): https://lists.fd.io/g/vpp-dev/message/10168
Mute This Topic: https://lists.fd.io/mt/24529319/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] NAT Fragment Reassembly

[Jon Loeliger]

On Wed, Aug 15, 2018 at 12:49 AM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Jon,
>
>
>
> NAT plugin does virtual fragment reassembly – it enables to translate
> non-initial fragments without L4 header otherwise NAT is unable to gather
> port information from the non-initial fragment, packet is still broken into
> several fragments after NAT translation.
>
>
>
> Matus
>

Thanks, Matus!

I'm trying to understand how part of the NAT virtual reassembly works still.
When and how does the drop_frag count come into play?  For example,
if an original packet was broken into 3 fragments, and drop_frag was 1 or 2,
should all three fragments get dropped?  And are they dropped on ingress
or egress?

Is there a packet trace flow where I can see them being dropped?  I ask
because it looks to me like these fragments are only sometimes dropped
when the drop_frag value is exceeded, and it also requires the
ip_reassembly_enable_disable to be "on" too.

I've been doing a "trace add dpdk-input 500", sending my example packets
that need fragmentation, NAT-ing them, and then filtering the trace buffer.
What is the right node to use in the "filter" here?

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

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

[vpp-dev] NAT Fragment Reassembly

[Jon Loeliger]

VPPeople,

A few months ago, the vppctl command 'set interface reassembly' was
added along with its API call, ip_reassembly_enable_disable (commit
4c53313cd7e9b866412ad3e04b2d91ac098c1398).

What is the relationship of this fragment reassembly and this
enable/disable flag WRT to the NAT's fragment reassembly?

Specifically, should a NAT fragment reassembly be controlled by this flag?
Empirically, the answer is 'yes'.

So it appears that one should interpret this enable/disable flag more like:

When you use `set interface reassembly  off`, the  fragments are
forwarded
without any sort of reassembly.  The fragments flow through
unmolested.  The NAT
fragmentation limits are not respected as they aren't even involved.

When you use `set interface reassembly  on`, the fragments are
reassembled
before being forwarded.  So the interface will process, and possibly
limit, fragment
reassembly, even for NAT rewritten packets.

Does that sound right?

And should the reassembly be enabled/disabled on the ingress interface?
Or are there different scenarios where one would want them reassembled on
the egress interface?

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

View/Reply Online (#10152): https://lists.fd.io/g/vpp-dev/message/10152
Mute This Topic: https://lists.fd.io/mt/24529319/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] How to use VPP API?

[Jon Loeliger]

On Mon, Jun 25, 2018 at 7:09 PM, Jeff Bushman  wrote:

> Is there any documentation, examples or discussion of how to use the VPP
> API Modules beyond the short documentation here?
> https://docs.fd.io/vpp/18.07/vapi_doc.html


Jeff,

If you are interested in the C API, there is also this:

https://wiki.fd.io/view/VPP/How_To_Use_The_C_API

HTH,
jdl

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

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

[vpp-dev] Missing functions?

[Jon Loeliger]

Hi!

With the current VPP top-of-tree here:

commit c7d50970d4ed8a4889b4374e6a1559aef7d3dcc0
Author: Andrew Yourtchenko 
Date:   Tue Jun 12 15:15:49 2018 +0200

acl-plugin: change the src/dst L3 info in 5tuple struct to be always
contiguous with L4 data

We seem to have some new linking issues like this:

/build-root/install-vpp-native/vpp/lib64/libvlib.so: undefined
reference to `_vlib_init_function_map_stat_segment_init'
/build-root/install-vpp-native/vpp/lib64/libvlib.so: undefined
reference to `_vlib_init_function_vpe_api_init'

Has anyone else seen issues like that?

Thanks,
jdl

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

View/Reply Online (#9598): https://lists.fd.io/g/vpp-dev/message/9598
Mute This Topic: https://lists.fd.io/mt/22083250/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] Static ARP Flag Question

[Jon Loeliger]

On Tue, May 15, 2018 at 8:53 PM, John Lo (loj)  wrote:

> Hi Jon,
>
>
>
> I am in the process of fixing up something in handling of IP neighbor
> pools.  I can include fixing the S/D bits of ARP flag in my patch, if you
> are not in a hurry to have this fixed.
>
>
>
> Regards,
>
> John
>

John,

Heh.  It has just now bubbled up to the top on my To Do list!
I'll look around to see if you beat me to it...

jdl

Re: [vpp-dev] Static ARP Flag Question

[Jon Loeliger]

On Thu, May 10, 2018 at 7:28 PM, John Lo (loj)  wrote:

> Hi Jon,
>

Hi John,


> This is not the right behavior.
>

I had that suspicion... :-)

  I think it is caused by reuse of a static ARP entry in  the IP4 neighbor
> pool with static bit still set.  The code merely set the dynamic bit in the
> flags but left the static bit untouched (similarly for the static path) in
> arp.c function vnet_arp_set_ip4_over_ethernet_internal ():
>
>
>
>   e->time_last_updated = vlib_time_now (vm);
>
>   if (is_static)
>
> e->flags |= ETHERNET_ARP_IP4_ENTRY_FLAG_STATIC;
>
>   else
>
> e->flags |= ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;
>

Ah, right.  So it should always be one or the other, and never both.  Right?

I spotted another error in the function vnet_arp_flush_ip4_over_
> ethernet_internal()
>
>
>
>  if (e->flags & ETHERNET_ARP_IP4_ENTRY_FLAG_STATIC)
>
> {
>
>   e->flags &= ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;
>
> }
>
>   else if (e->flags & ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC)
>
> {
>
>   arp_entry_free (eai, e);
>
> }
>
>
>
> I believe the “if static” path should be:
>
>   e->flags &= ~ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;
>
>
>
> Would you like to submit a patch to fix them?
>

Sure!  I will make a first-effort and submit a patch!

jdl

Re: [vpp-dev] Multiple Static Mappings

[Jon Loeliger]

On Wed, Apr 4, 2018 at 11:24 PM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES@Cisco) <matfa...@cisco.com> wrote:

> When using static mapping with port number external address/interface must
> be added to NAT pool otherwise static mapping won’t be resolved when
> interface obtain IP address. Run first “nat44 add interface address
> TenGigabitEthernet6/0/0” in your case.
>

Matus,

Sure, I can do that.  But my point is:  Why did it both "work" and "not
work"?
It _does_ add the mapping, and then it _does_ return an error.  My user
interface
is very confused by this!

If part of the mapping request is not fulfilled (not an interface IP
address available),
it should fail and NOT add the mapping.

Alternatively, if it is able to fulfill the mapping but just delayed, it
should
return a success code.

Thanks,
jdl


Matus
>
>
>
> *From:* Jon Loeliger <j...@netgate.com>
> *Sent:* Wednesday, April 4, 2018 5:41 PM
> *To:* Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <
> matfa...@cisco.com>
> *Cc:* vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] Multiple Static Mappings
>
>
>
> On Wed, Apr 4, 2018 at 5:34 AM, Matus Fabian -X (matfabia - PANTHEON
> TECHNOLOGIES@Cisco) <matfa...@cisco.com> wrote:
>
> Fixed https://gerrit.fd.io/r/#/c/11505/
>
>
>
> Matus
>
> Matus,
>
>
>
> Thanks for the quick turn-around on the bug fix!
>
>
>
> While the original problem (one local address with multiple externals)
> seems
>
> to have been fixed, there is still some lingering problem here.  It may
> simply
>
> be an issue with the return codes:
>
>
>
> vpp# nat44 add static mapping udp local 10.10.10.100 90 external
> TenGigabitEthernet6/0/0 
> nat44 add static mapping: External addres must be allocated.
> vpp# show nat44 static mapping
> NAT44 static mappings:
> udp local 10.10.10.100:90 external TenGigabitEthernet6/0/0: vrf -1
>
> vpp# nat44 add static mapping udp local 10.10.10.100 90 external
> TenGigabitEthernet6/0/0  del
> nat44 add static mapping: Mapping not exist.
> vpp# show nat44 static mapping
> NAT44 static mappings:
> vpp#
>
> It appears to properly add and delete the mappings, but the return
>
> code indicates that the operations have failed.
>
>
>
> Thanks,
>
> jdl._,
>

Re: [vpp-dev] Multiple Static Mappings

[Jon Loeliger]

On Wed, Apr 4, 2018 at 5:34 AM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES@Cisco)  wrote:

> Fixed https://gerrit.fd.io/r/#/c/11505/
>
>
>
> Matus
>
> Matus,

Thanks for the quick turn-around on the bug fix!

While the original problem (one local address with multiple externals) seems
to have been fixed, there is still some lingering problem here.  It may
simply
be an issue with the return codes:

vpp# nat44 add static mapping udp local 10.10.10.100 90 external
TenGigabitEthernet6/0/0 
nat44 add static mapping: External addres must be allocated.
vpp# show nat44 static mapping
NAT44 static mappings:
udp local 10.10.10.100:90 external TenGigabitEthernet6/0/0: vrf -1

vpp# nat44 add static mapping udp local 10.10.10.100 90 external
TenGigabitEthernet6/0/0  del
nat44 add static mapping: Mapping not exist.
vpp# show nat44 static mapping
NAT44 static mappings:
vpp#
It appears to properly add and delete the mappings, but the return
code indicates that the operations have failed.

Thanks,
jdl

[vpp-dev] Multiple Static Mappings

[Jon Loeliger]

Matus,

Are multiple static mappings for a single local address expected behavior?

vpp# nat44 add static mapping  icmp local 10.10.10.100 external 200.0.0.1
vpp# nat44 add static mapping  icmp local 10.10.10.100 external 200.0.0.2
vpp# nat44 add static mapping  icmp local 10.10.10.100 external 200.0.0.3
vpp# show nat44 static mapping
NAT44 static mappings:
 local 10.10.10.100 external 200.0.0.1 vrf 0
 local 10.10.10.100 external 200.0.0.2 vrf 0
 local 10.10.10.100 external 200.0.0.3 vrf 0

Thanks,
jdl

[vpp-dev] Removing a NAT static mapping

[Jon Loeliger]

Matus,

I have a question about the expected behavior for removing a
static mapping on an external interface address.

vpp# show int TenGigabitEthernet6/0/0 addr
TenGigabitEthernet6/0/0 (dn):
  L3 200.0.0.1/24
vpp# show nat44 static mappings
NAT44 static mappings:

And add a static mapping:

vpp# nat44 add static mapping  icmp local 10.10.10.100 external
TenGigabitEthernet6/0/0
vpp# show nat44 static mappings
NAT44 static mappings:
 local 10.10.10.100 external 200.0.0.1 vrf 0

Now, I tried to delete it:

vpp# nat44 add static mapping  icmp local 10.10.10.100 del
nat44 add static mapping: Mapping not exist.
vpp# nat44 add static mapping  icmp local 10.10.10.100 external
TenGigabitEthernet6/0/0 del
nat44 add static mapping: Mapping not exist.

I would have expected either of those two commands to have
removed the static mapping, but they do not.

This command, with an explicit external address does work:

vpp# nat44 add static mapping  icmp local 10.10.10.100 external 200.0.0.1
del
vpp# show nat44 static mappings
NAT44 static mappings:
vpp#

Is this the expected behavior here?  It seems to me that the mapping
should be able to be removed based on the (protocol, local-ip, local-port)
triplet and a little help from addr_only.

When it is not an interface address, that does seem to be sufficient:

vpp# nat44 add static mapping  icmp local 10.10.10.100
vpp# show nat44 static mapping
NAT44 static mappings:
 local 10.10.10.100 external 208.174.80.178 vrf 0
vpp# nat44 add static mapping  icmp local 10.10.10.100 del
vpp#

Furthermore, there apparently can not be multiple static mappings
for the same local-address:

vpp# nat44 add static mapping  icmp local 10.10.10.100 external
TenGigabitEthernet6/0/0
vpp# nat44 add static mapping  icmp local 10.10.10.100 external
TenGigabitEthernet6/0/0
nat44 add static mapping: Mapping already exist.
vpp#

So that triplet should make it a unique key for deletion, right?

Thanks,
jdl

Re: [vpp-dev] Some DS Lite Questions

[Jon Loeliger]

On Thu, Mar 29, 2018 at 2:58 PM, Jon Loeliger <j...@netgate.com> wrote:

> Matus, et al,
>
> Is there no way to remove either the B4 or AFTR tunnel endpoint once it is
> set?
>

So, I see one can use "::".  Is that the expectation here?

jdl

[vpp-dev] Some DS Lite Questions

[Jon Loeliger]

Matus, et al,

I am looking at the DS Lite CLI and API calls.  I have a few questions.

Is there no way to remove either the B4 or AFTR tunnel endpoint once it is
set?

It seems there is maybe a missing dslite_pool_addr_dump API call?

Is there a future for the ip4_addr fields on the "set B4" and "set AFTR"
API calls?

The CLI doesn't set them.  And while the Python API appears to be able to
set them, they are not used in any implementation anywhere.

Finally, is there any plan to make any of the NAT parameters (snat_config())
available via an API call?  I'm specifically thinking about the
"deterministic"
and "is_ce" flags.  It seems these, and perhaps others, could be set at
API handling time if we all agreed it mean flushing the current NAT state
and re-initializing things?

Thanks,
jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Tue, Mar 20, 2018 at 9:44 AM, Jon Loeliger <j...@netgate.com> wrote:

> On Tue, Mar 20, 2018 at 6:30 AM, Ole Troan <otr...@employees.org> wrote:
>
>>
>> >
>> > git clean -d -f -x .
>> > and rebuilding everything fixes the issue
>> >
>> > Let me know if you see a different issue...
>>
>
> Ooo, I see...  So, yeah, I have to hop between a local branch and the
> upstream master,
> so I may be being victimized by this problem.  I've been doing a "make
> wipe" or "wipe-release"
> and forgot about the industrial  'git clean'.  Drat.  I'll give that a
> run...
>

And for the record, I have rebuilt at this commit:

commit 6f4a6be8f222dd8caa94d19a7e4d87cb864ba7f4
Author: Neale Ranns <nra...@cisco.com>
Date:   Fri Mar 16 16:26:21 2018 -0700

Interface Unicast, Multicast and Broadcast stats on the API

 Change-Id: I7c75da358aff1bd0216a602a49f2909cef5d920d
Signed-off-by: Neale Ranns <nra...@cisco.com>

In a"git clean -fxd" directory and still see the PAPI "make test" errors.

jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Tue, Mar 20, 2018 at 6:30 AM, Ole Troan  wrote:

> > I debugged this a bit further and it seems that sometimes when hopping
> branches, the json files corresponding to APIs are not regenerated properly.
> > What happens in vpp-papi is that if it founds a duplicate, it checks
> whether it's the same message and if so, there is no exception raised.
> > But I saw that after Neale's recent update to vnet_combined_counter_t,
> in stats.api.json, the message was defined as before, while in
> interface.api.json, it was updated.
> > Doing a
> >
> > git clean -d -f -x .
> > and rebuilding everything fixes the issue
> >
> > Let me know if you see a different issue...
>

Ooo, I see...  So, yeah, I have to hop between a local branch and the
upstream master,
so I may be being victimized by this problem.  I've been doing a "make
wipe" or "wipe-release"
and forgot about the industrial  'git clean'.  Drat.  I'll give that a
run...

Ah right. So I guess this is caused by the lack of dependency tracking from
> the vppapigen compiler, that is for included files in .apis.
> I can modify vppapigen to add a new -M to output dependencies like what a
> C compiler does.
> Anyone has good ideas for how to add this into the GNU autotools stuff?
>

I can't believe I've read a sentence with the words "good ideas" and "GNU
autotools" in it. :-)


> Cheers,
> Ole


Cheers,
jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Mon, Mar 19, 2018 at 5:23 PM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Jon,
>
>
> Just to confirm - what's your environment?
>
>
Centos 7.4

jdl@bcc-1 $ uname -a
Linux bcc-1 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux

HTH,
jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Mon, Mar 19, 2018 at 10:55 AM, Burt Silverman  wrote:

> I believe the physmem/numa error is just to throw us off -- a code bug but
> an innocuous one at least for non NUMA systems; Damjan would know more.
>
> Jon, I like your idea about it not quitting on the first error. And I
> guess the "File Exists" error is also just something that happens after the
> "real" error. Roughly speaking, but maybe Klement can give us a more
> accurate statement about that.
>
> Burt
>

But that's just it.  Those tests go red-fail, then the whole local "make
test" fails, so I have
no real way of knowing when I submit a gerrit review if it is my problem or
not before I do so.

jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Mon, Mar 19, 2018 at 10:40 AM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Can you please provide instructions to reproduce?
>
> I checked out latest master
>

I think we are not communicating.

I checkout any top of tree commit over the past, oh three weeks
or so, and it fails.



> commit 2bc940272ec75d1094326eafb4a3fa2c614e3a7b
> Author: Neale Ranns 
> Date:   Sun Feb 25 12:27:18 2018 -0800
>
> Scapy upgrade to 2.4.0.rc5
>
> - many of the patches fd.io applies in test/patches/2.3.3 are now
> upstreamed in 2.4
> - 2.4 adds support for IGMPv3 which is my main motivation for the
> upgrade
>
> Change-Id: If2c0a524e3cba320b4a5d8cd07817c6ea2bf0c5a
> Signed-off-by: Neale Ranns 
>

These tests:


> And run both
>
> make test TEST=test_ip6
> make test-debug TEST=test_ip6


are not the problem.

jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Fri, Mar 16, 2018 at 3:33 AM, Klement Sekera  wrote:

> This looks kinda like you have old papi installed somewhere.
>
> Please try `make test-wipe` and let me know how it goes.
>
> Thanks,
> Klement


These are clean build of top-of-tree.  The 'make test-wipe' has no effect.

I think the problem is that it doesn't quit at the first error, and tries to
reopen one of the output files or directories a second time, not realizing
it is already there.



In one of the complaint directories, the stderr file contains this message:

$ less /tmp/vpp-unittest-TestPAPIMessageParsing-P8q8OK/vpp_stderr.txt

load_one_plugin:184: Loaded plugin: tlsmbedtls_plugin.so (mbedtls based TLS
Engine)
load_one_plugin:184: Loaded plugin: tlsopenssl_plugin.so (openssl based TLS
Engine)
work/vpp/build-root/install-vpp-native/vpp/bin/vpp[19872]:
unix_physmem_region_alloc:172: physmem page for region 'buffers' allocated
on the wrong numa node (requested 0 actual 4294967294)

In the log.txt we find:

10:12:52,305 --- setUp() for
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called ---
10:12:52,305 Starting sleep for 0.1s (during setUp)
10:12:52,405 Finished sleep (during setUp) - slept 0.100102901459s (wanted
0.1s)
10:12:52,405 CLI: clear trace
10:12:53,132 --- addError()
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called, err is (,
ValueError(u'Duplicate message name: vl_api_ip4_fib_counter_t',),
)
10:12:53,133 formatted exception is:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
testMethod()
  File "work/vpp/test/test_papi.py", line 281, in
test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t

10:12:53,133 creating a link to the failed test
10:12:53,133 os.symlink(/tmp/vpp-unittest-TestPAPIMessageParsing-P8q8OK,
/tmp/vpp-failed-unittests//vpp-unittest-TestPAPIMessageParsing-P8q8OK-FAILED)
10:12:53,133 --- tearDown() for
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called ---
10:12:53,134 CLI: show trace

HTH,
jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Thu, Mar 15, 2018 at 4:45 PM, Dave Barach  wrote:

> +1. Definitely try “make test” as root, and let folks know how it goes…
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Damjan
> Marion
> *Sent:* Thursday, March 15, 2018 5:24 PM
> *To:* vpp-dev@lists.fd.io
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] make TEST=test_ip6 test failing on multiple
> machines, when NOT run as root.
>
>
>
>
>
> OK, this doesn't look like related  to my issue. does it work with sudo?
>

So, yes.  Even sudone, these remaining errors persist.

Not sure what is at work here yet.

jdl

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Thu, Mar 15, 2018 at 1:54 PM, Damjan Marion 
wrote:

>
> Should be fixed now, issue was happening when VPP was allocating buffer
> memory from 4K pages (running as non-root).
>


Damjan,

It has gotten better, but I still see these:

==
PAPI Message parsing Test Case
==
New compound type with array
 ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:04,318 [Errno 17] File exists
Add new types
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Add new types 2  OK
15:09:05,997 [Errno 17] File exists
Add new message object
 ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:06,908 [Errno 17] File exists
New message with array
 ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Argument nameOK
VLA with aribtrary length field placementOK
15:09:09,451 [Errno 17] File exists
Message to byte encoding
 ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:10,370 [Errno 17] File exists
Nested array type
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Old style VLA array  OK
15:09:12,125 [Errno 17] File exists
Old VLA compound type
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]


MPLS IPv4 Multicast Tail
 ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestMPLS-bWDeO0 ]


Later, the output also has these:


==
ERROR: New compound type with array
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
281, in test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t

==
ERROR: Add new types
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
167, in test_add_new_types
msglist.add_type(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t

==
ERROR: Add new message object
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 71,
in test_adding_new_message_object
msgdef = msglist.add_message(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version

==
ERROR: New message with array
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 87,
in test_adding_new_message_object_with_array
msglist.add_message(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: ip_address_details

==
ERROR: Message to byte encoding
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 95,
in test_message_to_bytes
msgdef = msglist.add_message(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version

==
ERROR: Nested array type

Re: [vpp-dev] Ccache vs VPPAPIGEN

[Jon Loeliger]

On Thu, Mar 15, 2018 at 2:00 PM, Damjan Marion 
wrote:

>
> Lot of changes happened in this area in last 48 hours. There is no
> bootstrap step needed anymore.
>
> Do you still see issues?
>

Damjan,

I believe your changes have fixed things.

Thanks!

jdl

[vpp-dev] vppsb's librtnl is broken with top of VPP tree

[Jon Loeliger]

Hey VPP-dev

Is it me?  It's me, isn't it.

jdl




librtnl/mapper.c: In function 'mapper_add_del_route':
librtnl/mapper.c:101:31: error: passing argument 10 of
'fib_table_entry_path_add' from incompatible pointer type [-Werror]
   FIB_ROUTE_PATH_FLAG_NONE);
   ^
In file included from
/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib.h:647:0,
 from librtnl/mapper.c:25:
work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib_table.h:332:25:
note: expected 'struct fib_mpls_label_t *' but argument is of type
'mpls_label_t *'
 extern fib_node_index_t fib_table_entry_path_add(u32 fib_index,
 ^
librtnl/mapper.c:132:31: error: passing argument 10 of
'fib_table_entry_path_add' from incompatible pointer type [-Werror]
   FIB_ROUTE_PATH_FLAG_NONE);
   ^
In file included from
work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib.h:647:0,
 from librtnl/mapper.c:25:
work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib_table.h:332:25:
note: expected 'struct fib_mpls_label_t *' but argument is of type
'mpls_label_t *'
 extern fib_node_index_t fib_table_entry_path_add(u32 fib_index,
 ^
cc1: all warnings being treated as errors
make[3]: *** [librtnl/mapper.lo] Error 1
make[3]: Leaving directory
`/vppsb/netlink/build-root/rpmbuild/BUILD/netlink-1.0.1-22~gd8e6dbc-dirty'
error: Bad exit status from /var/tmp/rpm-tmp.IlCmHt (%build)

Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.

[Jon Loeliger]

On Tue, Mar 13, 2018 at 5:47 AM, Klement Sekera  wrote:

> I would say that this should be worth the extra effort just to have the
> same conditions. Otherwise the verify job does something different than
> `make test` on your box and that could be confusing.
>
> Thanks,
> Klement


These days, 'make test' on my box(*) running as not-root fails many tests.
I've not looked into it, but here are some.  I'm going with duplicate API
message registration?

HTH,
jdl

(*) -- CentOS 7.4.1708



PAPI Message parsing Test Case
==
New compound type with array
 ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-f22YXN ]
13:33:25,146 [Errno 17] File exists



ERROR: New compound type with array
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
281, in test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t

==
ERROR: IPv6 FIB test
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_ip6.py", line 343,
in test_fib
pkts = self.pg0.get_capture()
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/vpp_pg_interface.py",
line 242, in get_capture
raise Exception("No packets captured on %s" % name)
Exception: No packets captured on pg0


ERROR: Add new message object
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 71,
in test_adding_new_message_object
msgdef = msglist.add_message(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version


ERROR: New message with array
--
Traceback (most recent call last):
  File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 87,
in test_adding_new_message_object_with_array
msglist.add_message(p[0], p[1:])
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: ip_address_details

Re: [vpp-dev] VPP As A Router Between Namespaces - 10ms latency

[Jon Loeliger]

On Mon, Mar 12, 2018 at 3:57 AM, Sara Gittlin 
wrote:

> Dear Florin,
>
> When using the command " create tap rx-ring-size 4096 tx-ring-size 4096 "
>  VPP create the devices with default names tap0, tap1, ..tapn.
>
> Is it possible for the user to set the name in the 'create' command line ?
>
> Thank you in advance
> -Sara


Hi Sara,

Welcome to my battle!

Luckily, there is a way to do as you wish!  If you set the "instance"
value  during the tap_create API call, or use "id " during the
"create tap ..." CLI command, you will create an interface of the
name "tap".  You may not use a different prefix than "tap", but
at least you can know what the name will be when it is created.

HTH,
jdl

[vpp-dev] A Question about SPAN Dump Details

[Jon Loeliger]

John, et al,

Could we add the "is_l2" flag into the SPAN details message
so that we don't have to maintain global state about what type
of detail is coming back?

Happy to submit that patch if you are OK with the suggestion.

Thanks,
jdl

Re: [vpp-dev] Tap and Tap-inject

[Jon Loeliger]

On Wed, Feb 28, 2018 at 5:59 PM, Jon Loeliger <j...@netgate.com> wrote:

> Discuss:
>
> Two Things That Don't Work Together:  Tap and Tap-inject
>
> In today's world of discord, we often stray into territory that seems
> benign and harmless;  a world that should be harmonious and
> fruitful.  Yet, a cursory inspection yields quizzical behavior, mysterious
> happenings, and hidden messages.  This is the world of Tap and
> Tap-injection after lifting the rock cap hiding them.
>

Hi Guys-n-Gals,

I have posted the following patch to address this issue:

https://gerrit.fd.io/r/#/c/10942/

HTH,
jdl

Re: [vpp-dev] Upcoming memif API and CLI changes.

[Jon Loeliger]

Peter,


> Trying to configure Memif:
>
>
>
> vat# memif_dump
>
> Sending ping id=714
>
> memif0/0: sw_if_index 3 mac 02:fe:db:be:87:29
>
>id 0 socket-id 0 role slave
>
>ring_size 1 buffer_size 0
>
>state down link down
>

If you also dump the memif socket table you should see
that socket-id 0 is the default socket filename.

Which means ...

> vat# memif_socket_filename_add_del add id 0 filename /tmp/memif
>
> Invalid socket idmemif_socket_filename_add_del error: Misc
>

 you can neither create nor delete that socket-id 0.


> vat# memif_socket_filename_add_del add id 1 filename /tmp/memif
>
> memif_socket_filename_add_del error: Misc
>
>
>
> vat# memif_create id 0 socket-id 1 master
>
> memif_create error: Invalid argument
>

That might be an issue...  And it might be localized to VAT because:

vpp# create memif socket id 1 filename /tmp/foo.sock
vpp# show memif
sockets
  id  listenerfilename
  0   no  /run/vpp/memif.sock
  1   no  /tmp/foo.sock

I'll peer at VAT unless John Lo beats me to it. :-)

jdl

[vpp-dev] VXLAN Instances Not Freed Properly?

[Jon Loeliger]

John, et al,

I stumbled across this interesting behavior in VXLAN tunnels:

vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101
vxlan_tunnel101
vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101 del
vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101
create vxlan tunnel: Instance is in use

And note the actual interface has been removed, so 101 should be free:

vpp# show int
  Name   Idx   State  Counter
Count
TenGigabitEthernet6/0/0   1down
TenGigabitEthernet6/0/1   2down
TenGigabitEthernet6/0/2   3down
TenGigabitEthernet6/0/3   4down
local00down

I was pretty sure this was working, but I might have botched that patch
somehow?
Any chance you stumbled into this problem?

It might be worth noting that the equivalent GRE does work:

vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14
gre14
vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14 del
DELETED
vpp# create gre  tunnel src 1.2.3.4 dst 10.11.12.13 instance 14
gre14

I feel like this might be some typo or easy oversight in the VXLAN case.

Thanks,
jdl

[vpp-dev] _mm_testz_si128 Woes

[Jon Loeliger]

Hey hey hey,

I tried to build a variant of vppsb and failed miserably
for lack of the __mm_testz_si128 symbol.

>From whence does that arrive on my doorstep?

I'm trying to figure out if vppsb needs to #define something new,
or #include something first, or if my system is suddenly missing
something assumed to be present and VPP cleverly allowed for
it to be missing while vppsb was less so?

Thanks,
jdl






```libtool: compile:  gcc -DPACKAGE_NAME=\"netlink\"
-DPACKAGE_TARNAME=\"netlink\" "-DPACKAGE_VERSION=\"1.0.1-21~g888408a\""
"-DPACKAGE_STRING=\"netlink 1.0.1-21~g888408a\"" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"netlink\"
"-DVERSION=\"1.0.1-21~g888408a\"" -I. -Wall -fstack-protector -fPIC -Werror
-g -DFORTIFY_SOURCE=2 -O2
-I/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -c librtnl/netns.c  -fPIC -DPIC -o librtnl/.libs/netns.o
In file included from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector.h:262:0,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/mheap_bootstrap.h:47,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/mem.h:47,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vec.h:42,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/format.h:44,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/elf.h:41,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/elf_clib.h:41,
 from
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vlib/vlib.h:44,
 from ./librtnl/netns.h:19,
 from librtnl/netns.c:16:
/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector_sse2.h:
In function 'u8x16_is_all_zero':
/home/jdlwork/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector_sse2.h:552:3:
error: implicit declaration of function '_mm_testz_si128'
[-Werror=implicit-function-declaration]
   return _mm_testz_si128 ((__m128i) x, (__m128i) x);
   ^
cc1: all warnings being treated as errors
```

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

John,

On Mon, Feb 5, 2018 at 2:14 PM, John Lo (loj)  wrote:

> Thanks Jon.  Seems we have an agreed upon an approach now.  Just to be
> sure, let me list the specifics:
>
>
>
> 1.  We will get rid of custom_instance_by_real_instance vector in
> vxlan_main_t
>
See #3 below.

> 2.  We will add something like user_instance_by_real_instance hash in
> vxlan_main_t to track instance usage.
>
Yes.

> 3.  We will add u32 instance in vxlan_tunnel_t to keep user specified
> instance, which will be the same as real instance or index of vxlan tunnel
> in the tunnels vector in vxlan_main.
>
> I am happy to do this, yes.  However, there is some reason that this
number can not be used directly within the format() of the vxlan_tunnel%d
name.
At the time that the reuse of the HW IF happens, the necessary
name_renumber()
call fails to get the right instance number as the hw_if_index isn't set in
the hi struct
properly yet.  This is why the custom_instance_by_real_instance mechanism
works:
it is always available.

I will endeavor to use just the hash and the instance on the tunnel struct.
I will attempt to resolve the issue described in the previous paragraph in
more detail.
I know that was a bit vague, so I'll attempt to nail-down the real issue I
was seeing.

4.  We will replace the 64 byte if_name in the vxlan_tunnel_details API
> with u32 instance.
>
Yes.

> 5.  We will generate instance-in-use API error if vxlan tunnel
> creation cannot use the desired instance, either natural or specified.
>
Yes.

We also have to guarantee that: in the case of default allocation (ie, not
specified by the user/API), that there still always a successful allocation.
(Ie, a bit of searching for a valid instance might take place.)  I don't
think
this will be a problem in general.  it will likely only be noticed when both
default and specified allocations are intermixed.


> Will review your new patch set when it shows up.  Once you patch is
> merged, I will copy the same mechanism into the GRE tunnel update I am
> currently working. I will submit my GRE patch for review sometime later and
> add you as one of the reviewers.
>

Awesome!  Sounds great!


> Thanks,
>
> John
>

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Mon, Feb 5, 2018 at 11:48 AM, John Lo (loj)  wrote:

> One more thang, I would prefer to have a u32 instance number instead of
> the 64 bytes if_name in the vxlan_tunnel_details API.   -John
>

Hi John,

I'll work up a patch re-spin using a hash-table, and I will
include the if_name -> sw_if_index change mentioned above!

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Mon, Feb 5, 2018 at 9:55 AM, Jon Loeliger <j...@netgate.com> wrote:

>
>
>
>> I think we must check and reject instance misuse for this to be
>> acceptable. I doubt the renumber is really used much for vhost and tap
>> interface (others please correct me if not true).
>>
>
> We do use them on every call we make to these functions.
> As well as on loopbacks.  Knowing what object (by name) will b
> created is essential for us.
>
>
>>
>>
> In your previous patch set #1, the usage of a bitmap to track instance
>> usage seem a reasonable solution. It does imply we will never use “natural”
>> instance and would always use the instance allocated from the bitmap and
>> stored in the tunnel struct.
>>
>
> That said, we can combine the two approaches.  That is, use the
> show_instance_by_real_instance vector for knowing what name to use,
> but also use a bitmap to record what  was used and allocated.
>
> One question on the bitmap approach.  It had a hard-coded upper limit of
> 16K
> bits in my previous patch.  Are people OK with that?  It is arbitrary, and
> could
> be larger.  It simply depends on how much memory folks are willing to spend
> recording in-use bits.  That or a search of the show_by_real vector.  Or we
> could convert to a hash-map to check "in-use" status.
>
> Preference?
>

John,

Also as a point of information, I'd like to follow this approach for GRE as
well
as soon as we agree on an approach here!

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Mon, Feb 5, 2018 at 9:29 AM, John Lo (loj)  wrote:

> Hi Jon,
>

Hi John,


> I don’t think the renumber scheme, as used by vhost and tap interfaces, is
> foolproof and can cause problems if used extensively for vxlan.  On
> creating an interface with renumber, it does not check if the instance
> being requested is already used by another device. On creating an interface
> without renumber, it also does not check if the “natural instance’ may have
> already been used by another device’s renumber.  Thus, on instance
> collision, last interface will take over the interface name and leave the
> previous interface  not accessible by the duplicated interface name.
>

I was solving that the UI level, but it could be added into the
vxlan_add_del_interface() layer as well.


> I think we must check and reject instance misuse for this to be
> acceptable. I doubt the renumber is really used much for vhost and tap
> interface (others please correct me if not true).
>

We do use them on every call we make to these functions.
As well as on loopbacks.  Knowing what object (by name) will b
created is essential for us.


>   I see a “FIXME” warning in the existing vhost renumber function:
>
>
>
> static int
>
> vhost_user_name_renumber (vnet_hw_interface_t * hi, u32 new_dev_instance)
>
> {
>
>   // FIXME: check if the new dev instance is already used
>
>   vhost_user_main_t *vum = _user_main;
>
>   vec_validate_init_empty (vum->show_dev_instance_by_real_dev_instance,
>
>  hi->dev_instance, ~0);
>

Hmmm, yes, I see ...


> In your previous patch set #1, the usage of a bitmap to track instance
> usage seem a reasonable solution. It does imply we will never use “natural”
> instance and would always use the instance allocated from the bitmap and
> stored in the tunnel struct.
>

This procedure fails for some reason on the 5th test in VXLAN tests.
I am not certain, but I think it is because the renumbering effort was
trying to get the desired instance number out of the tunnel struct,
which lead to finding the corresponding vnet_hw_interface, and when
it needed to renumber, the hi->hw_if_index or hi->dev_instance wasn't
yet set, and it ended up creating IFs with wrong names (always 0?).

That said, we can combine the two approaches.  That is, use the
show_instance_by_real_instance vector for knowing what name to use,
but also use a bitmap to record what  was used and allocated.

One question on the bitmap approach.  It had a hard-coded upper limit of 16K
bits in my previous patch.  Are people OK with that?  It is arbitrary, and
could
be larger.  It simply depends on how much memory folks are willing to spend
recording in-use bits.  That or a search of the show_by_real vector.  Or we
could convert to a hash-map to check "in-use" status.

Preference?

As for the API/CLI, I though another parameter “instance” would suffice as
> ~0 can be used to state “not specified” rather than having an additional
> parameter “renumber”, although I can accept either way.
>

Two things here.  I'm fine with either as well.  I was following the
existing
pattern for the "renumber" approach.  Using ~0 effectively means that the
message constructors must all explicitly initialize this field to ~0.  I'm
good
with that (previous patch!) if you guys are as well.

Regards,
>
> John
>

Thanks for your feedback!

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj)  wrote:

> Hi Jon,
>
>
>
> All VPP tunnel creation uses the mechanism of returning a sw_if_index of
> the created tunnel. The name of the tunnel is then followed by a number
> being the instance or index to the tunnel struct vector. Thus, the first
> VXLAN tunnel created is called vxlan_tunnel0 followed by vxlan_tunnel1,
> etc. The number is incrementing unless tunnels are deleted and created
> again where a newly created tunnel will reuse the last deleted tunnel,
> hence its name. If all previously deleted tunnels are used up, then the
> tunnel name number will start incrementing again.  I am not sure if it is
> feasible to follow this behavior to “predict” tunnel name.
>

John and Dave,

I have uploaded a new patch set.  It is being verified at the time of this
writing.

This patch has a different implementation than the previous version.
The API changes, including VAT-n-friends, have been updated a bit,
but the basic mechanism of obtaining predictable SW IF names is
different from my original patch.

In the current form, I followed an existing "custom device instance" pattern
that was already present on several other objects already.  Much simpler,
and I expect it to verify now. :-)

So, I guess I realize my mistake in my previous discussions of this general
problem
I apparently wasn't using the right words.  I was saying something like
"The User
needs to be able to know or predict the SW IF name."  The phrase that seems
to
be used specifically for this purpose in many other places is "Let the user
assign
a custom device instance id."  And that is achieved via the use of the
so-called
*_name_renumber() class function.

So my earlier plea for a "can we somehow solve this at a higher level" might
be more properly stated as:  Where objects are created as a side-effect of
some other creation request, a "renumber flag and custom device instance"
would be really nice on the Create API call.

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Fri, Feb 2, 2018 at 3:08 PM, Jon Loeliger <j...@netgate.com> wrote:

>
> I have submitted a patch to Gerrit.  When this passes "verify", I'll add
> you to be
> a Reviewer!
>

John,

How do I run just these tests locally?  I need to determine if
these failures are due to my patch or not.

Specifically, I am not able to succesfully "make test" on a CentOS system
due to Python having a memory corruption failure and dumping core on me.
As many tests until that point were passing though.

I'll add you as a patch reviewer anyway -- maybe you can spot something
brain-dead that I did in the patch...?

Thanks,
jdl


*20:46:28* 20:33:41
*20:46:28*
20:33:41 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ecmp-Func :: *Ipv6
Multipath routing test cases*
   *20:46:28* 20:33:41
*20:46:28*
20:34:06 TC01: IPv6 Equal-cost multipath routing :: [Top] TG=DUT
  |
PASS |*20:46:28* 20:34:06
*20:46:28*
20:34:06 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ecmp-Func :: *Ipv6
Multipath routing test cases* |
PASS |*20:46:28* 20:34:06 1 critical test, 1 passed, 0
failed*20:46:28* 20:34:06 1 test total, 1 passed, 0 failed*20:46:28*
20:34:06 
*20:46:28*
20:34:06 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ra-Func :: *IPv6
Router Advertisement test cases*
 *20:46:28* 20:34:06
*20:46:28*
20:34:20 TC01: DUT transmits RA on IPv6 enabled interface :: [Top]
TG-DUT1-DUT2-TG.
| PASS |*20:46:28* 20:34:20
*20:46:28*
20:34:36 TC02: DUT retransmits RA on IPv6 enabled interface after a
set interval :: [Top] TG-DUT1-DUT2-TG.   |
PASS |*20:46:28* 20:34:36
*20:46:28*
20:34:49 TC03: DUT responds to Router Solicitation request :: [Top]
TG-DUT1-DUT2-TG. |
FAIL |*20:46:28* 20:34:49 Traffic script execution failed*20:46:28*
20:34:49 
*20:46:28*
20:35:02 TC04: DUT responds to Router Solicitation request sent from
link local address :: [Top] TG-DUT1-DUT2-TG.|
FAIL |*20:46:28* 20:35:02 Traffic script execution failed*20:46:28*
20:35:02 
*20:46:28*
20:35:02 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ra-Func :: *IPv6
Router Advertisement test cases*|
PASS |*20:46:28* 20:35:02 0 critical tests, 0 passed, 0
failed*20:46:28* 20:35:02 4 tests total, 2 passed, 2 failed*20:46:28*
20:35:02 

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

Re: [vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj)  wrote:

> Hi Jon,
>

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of
> the created tunnel.
>

I know.  I get that.  It works.


> The name of the tunnel is then followed by a number being the instance or
> index to the tunnel struct vector. Thus, the first VXLAN tunnel created is
> called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is
> incrementing unless tunnels are deleted and created again where a newly
> created tunnel will reuse the last deleted tunnel, hence its name. If all
> previously deleted tunnels are used up, then the tunnel name number will
> start incrementing again.
>

Right.


> I am not sure if it is feasible to follow this behavior to “predict”
> tunnel name.
>

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB
> (transparent ethernet bridging) support to GRE. Have you not been using it
> and bothered by how to predict name of created GRE tunnels?
>

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to
> identify VXLAN tunnels. It is quite common for existence of multiple VXLAN
> tunnels with the same VNI with different remote end point IP addresses. A
> bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to
> several remote servers where the same overlay network exist. It is quite
> common to use the ID for BD or VLAN as the VNI for all its VXLAN tunnels to
> make it easier to track their usage.
>

Excellent!  Thank you for this insight!  That makes total sense now!

I suppose it is feasible to provide another set of VXLAN tunnel
> create/delete API to allow caller to specify instance or number of the
> tunnel, similar to what you did for loopback interface.
>

This is the route I was headed:  Just like loopback interface naming!

In this case, the above example would be, perhaps, something like this:

vxlan MyVxlan23
instance 101
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface vxlan_tunnel101
do stuff to interface like apply an ACL or whatever
exit


  One complication for the new API is that, upon VXLAN tunnel deletion, the
> interface created for the tunnel is not really deleted by the current code
> but put into a reuse pool.
>

I solved that by making a trivial  vxlan_name_renumber()  function,
and then calling vnet_interface_name_remumber(sw_if_index, instance)
to update the previously captured "vxlan_tunnel" name and rename
it using the new instance number.

When more tunnels are created, any interface from reuse pool with its
> existing interface name will be used for the new tunnel, before new
> interfaces are created. If a interface is reused upon tunnel creation, its
> interface name may not match the specified tunnel instance/number of the
> new tunnel creation API.  One way to overcome this may be to not keep
> interface in reused pool on tunnel deletion. Thus, tunnel creation would
> always create new interface.  For backward compatibility, I suppose we can
> keep the tunnel create/delete API as is so interfaces of deleted tunnels
> are kept for reuse. The new API will then always create/delete interface on
> tunnel create/delete.  This would put a restriction that user should not
> mix the usage of new or old APIs.
>

To me, that sounds like a whole bunch of really unnecessary code replication
and fragile separation of API results that will invariably get mixed up and
cause mysterious failures.

Instead, I maintain the original instance allocation scheme when there is
no requested Instance Id made by the CLI or API user.

I have submitted a patch to Gerrit.  When this passes "verify", I'll add
you to be
a Reviewer!

[vpp-dev] Consolidatation of fib_ip_proto() functions?

[Jon Loeliger]

Neale,

I have need of using a function like fib_ip_proto(), below, in yet another
file.
But rather than introduce a 5th copy of the same function, would you
accept a patch that consolidated them all into one static inline in, say,
fib_types.h where the FIB_PROTOCOL_* values are defined?

Thanks,
jdl


static inline fib_protocol_t
fib_ip_proto(bool is_ip6)
{
  return (is_ip6) ? FIB_PROTOCOL_IP6 : FIB_PROTOCOL_IP4;
}


jdl@bcc-1 $ git grep fib_ip_proto src/
src/plugins/gtpu/gtpu.c:fib_ip_proto (bool is_ip6)
src/plugins/gtpu/gtpu.c:  fib_protocol_t fp = fib_ip_proto (is_ip6);
src/plugins/gtpu/gtpu.c:  encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
src/vnet/geneve/geneve.c:fib_ip_proto (bool is_ip6)
src/vnet/geneve/geneve.c: fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/geneve/geneve.c: encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
src/vnet/vxlan-gpe/vxlan_gpe.c:fib_ip_proto (bool is_ip6)
src/vnet/vxlan-gpe/vxlan_gpe.c:   fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/vxlan/vxlan.c:fib_ip_proto(bool is_ip6)
src/vnet/vxlan/vxlan.c:  fib_protocol_t fp = fib_ip_proto(is_ip6);
src/vnet/vxlan/vxlan.c:encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VXLAN Tunnel IF Names

[Jon Loeliger]

Hey Developers,

I've turned my attention to the wondrous world of VXLANs!
And with that, I stare into the Vast VXLAN API Abyss...

My first question, as usual, involves the SW IF that is created
by the vxlan tunnel create API call.   The IF has a name that
is once-again unknowable by the User who creates the tunnel
unless direct inspection takes place.

Can we somehow invert the naming responsibility here so that
the API states either the name or the unique integer used to
form the the SW IF tunnel name?  Or perhaps it can be formed
using the VNI number?

Inspecting the reply return value isn't good enough; we need to
be able to know, in advance, what the tunnel SW IF name will be.
This is, again, the same naming problem we've had in the past
with Loopback IFs, bridges, and recently memif socket names.

If directly using the VNI won't work, I can work up a patch to
allow user numbering in the style of, say, bridges, if that would
be helpful.

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

Re: [vpp-dev] Building APIs outside of the VPP tree

[Jon Loeliger]

On Sun, Jan 28, 2018 at 2:42 PM, Ole Troan  wrote:

> Thanks for fixing it Jon!
> I'm not sure there is anything much better than that. ;-)
>
> Cheers,
> Ole


I'll submit a real patch to Gerrit then.

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

Re: [vpp-dev] Building APIs outside of the VPP tree

[Jon Loeliger]

On Sat, Jan 27, 2018 at 3:37 PM, Jon Loeliger <j...@netgate.com> wrote:

> Folks,
>
> I have updated to top-of-vpp master, now at commit:
>
> commit fc804d9cf1d23a616ea7bce19fc65198aa978e6e
> Author: Florin Coras <fco...@cisco.com>
> Date:   Fri Jan 26 01:27:01 2018 -0800
>
> Fix session/tcp coverity warnings
>
> I am trying to build a VPP API outside of the VPP tree.
> It now wants to run this rule:
>
> %.api.h: %.api
> vppapigen --input $^ --output $@
>
> Which is fine.
>
> It ends up using the VPP package install of /usr/bin/vppapigen,
> but that in turn wants to use ../share/cpp/C.py.  That however,
> appears not to be installed:
>
> Exception: Error importing output plugin: /usr/bin/../share/vpp/C.py,
> [Errno 2] No such file or directory
>
> Did I miss a step somewhere?  Or should the RPM bundle that up
> and install it as well now?
>
> Thanks,
> jdl
>

Ole,

I applied this patch and it appears to work.

I am relatively certain there is a better patch trying to get out here. :-)

HTH,
jdl


diff --git a/extras/rpm/vpp.spec b/extras/rpm/vpp.spec
index 532b9a2..830ba4f 100644
--- a/extras/rpm/vpp.spec
+++ b/extras/rpm/vpp.spec
@@ -228,6 +228,9 @@ for i in $(ls
%{_mu_build_dir}/../src/vpp-api/java/jvpp/gen/jvppgen/*.py); do
install -p -m666 ${i} %{buildroot}%{python2_sitelib}/jvppgen
 done;

+install -p -m 644 %{_mu_build_dir}/../src/tools/vppapigen/C.py
%{buildroot}/usr/share/vpp
+install -p -m 644 %{_mu_build_dir}/../src/tools/vppapigen/JSON.py
%{buildroot}/usr/share/vpp
+
 # sample plugin
 mkdir -p -m755 %{buildroot}/usr/share/doc/vpp/examples/sample-plugin/sample
 #for file in $(cd
%{_mu_build_dir}/%{_vpp_install_dir}/../../src/examples/sample-plugin &&
git ls-files .)
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Building APIs outside of the VPP tree

[Jon Loeliger]

Folks,

I have updated to top-of-vpp master, now at commit:

commit fc804d9cf1d23a616ea7bce19fc65198aa978e6e
Author: Florin Coras 
Date:   Fri Jan 26 01:27:01 2018 -0800

Fix session/tcp coverity warnings

I am trying to build a VPP API outside of the VPP tree.
It now wants to run this rule:

%.api.h: %.api
vppapigen --input $^ --output $@

Which is fine.

It ends up using the VPP package install of /usr/bin/vppapigen,
but that in turn wants to use ../share/cpp/C.py.  That however,
appears not to be installed:

Exception: Error importing output plugin: /usr/bin/../share/vpp/C.py,
[Errno 2] No such file or directory

Did I miss a step somewhere?  Or should the RPM bundle that up
and install it as well now?

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