Re: [vpp-dev] Some NAT API Error Values
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
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 = &snat_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 = &snat_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
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, >&adj->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
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, &adj->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
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
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
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
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?
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?
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?
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
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
On Fri, May 15, 2020 at 2:38 PM Jon Loeliger wrote: > > 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 > Ole et al, I have a better understanding of what is going on now. The key understanding necessary is this: The phrase "address only", and the variable "addr_only" within the static NAT code means "no port and no protocol". If one sets a port, even if 0, the "address only"-ness is now "false". However, the same is NOT true for using a protocol. But the both the ports and protocol are nonetheless ignored in the NAT lookup keys later via checks on the addr_only flag. Bottom line here is this: Correct and expected behavior for ICMP traffic can be achieved from the vppctl command by specifying ports even though they are irrelevant to ICMP traffic. Proper "address only" mappings (ie, no ports and no protocol) should not need to have a protocol specified. And hey, if I am way off base here, please come shake my cage. HTH, jdl -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16413): https://lists.fd.io/g/vpp-dev/message/16413 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] Question regarding ICMP NAT behavior
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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
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
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
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?
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
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
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
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
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
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 = &nat_ha_main; snat_main_t *sm = &snat_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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] A few MAP-T Clarifications
Hey, sorry to pester folks... Anyone have any insight here for us? Thanks, jdl On Wed, Apr 10, 2019 at 8:12 AM Jon Loeliger wrote: > 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 (#12788): https://lists.fd.io/g/vpp-dev/message/12788 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] A few MAP-T Clarifications
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
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
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
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
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
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
[ 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
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
[vpp-dev] Static ARP Flag Question
VPP-ers, Is this expected behavior for the Flags here? Thanks, jdl vpp# set int ip address TenGigabitEthernet6/0/0 10.10.20.1/24 vpp# set interface state TenGigabitEthernet6/0/0 up vpp# set ip arp TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56 static vpp# show ip arp Time IP4 Flags Ethernet Interface 53.7857 10.10.20.100 S08:00:27:41:a7:56 TenGigabitEthernet6/0/0 vpp# set ip arp del TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56 static vpp# show ip arp vpp# set ip arp TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56 vpp# show ip arp Time IP4 Flags Ethernet Interface 90.9054 10.10.20.100SD08:00:27:41:a7:56 TenGigabitEthernet6/0/0
Re: [vpp-dev] Multiple Static Mappings
On Wed, Apr 4, 2018 at 11:24 PM, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) 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 > *Sent:* Wednesday, April 4, 2018 5:41 PM > *To:* Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) < > matfa...@cisco.com> > *Cc:* vpp-dev > *Subject:* Re: [vpp-dev] Multiple Static Mappings > > > > 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._, >
Re: [vpp-dev] Multiple Static Mappings
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
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
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
On Thu, Mar 29, 2018 at 2:58 PM, Jon Loeliger 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
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.
On Tue, Mar 20, 2018 at 9:44 AM, Jon Loeliger wrote: > On Tue, Mar 20, 2018 at 6:30 AM, Ole Troan 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 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 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.
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.
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.
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.
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.
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.
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.
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
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] Ccache vs VPPAPIGEN
Good Evening Sports Fans, Have we got a match for you tonight! In this corner, ccache. Loved for it speed and hackery, hated for its invasive corruptibility. In the other corner, we have vppapigen, loved tool of the single-source definitions for all things yet hated as the monster that will not die! Tonight we bring them together in the top-level Makefile, in a clause that might leave a few, myself included, mystified: ifeq ("$(wildcard /usr/bin/ccache )","") @echo "WARNING: Please install ccache AYEC and re-run this script" else @rm -rf $(BR)/tools/ccache-bin @mkdir -p $(BR)/tools/ccache-bin @ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/gcc @ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/g++ @ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/clang @ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/clang++ mkdir -p $(BR)/tools/bin rm -f $(BR)/tools/bin/vppapigen ln -s $(WS_ROOT)/src/tools/vppapigen/vppapigen \ $(BR)/tools/bin/vppapigen ls -lsa $(BR)/tools/bin endif @touch $@ You might recognize that as part of the $(BR)/.bootstrap.ok target! It is! You could win! But first, let's see what happens when ccache is NOt installed on the build machine! Yep, you get that warning: @echo "WARNING: Please install ccache AYEC and re-run this script" Naturally, that is lost way, way, back at the beginning of the scroll-back. Twenty minutes of scroll-back. Unless Yes, in just under 2 minutes, the build fails! Quizically like this: APIGEN vlibmemory/memclnt.api.h JSON API vlibmemory/memclnt.api.json /bin/sh: line 2: vppapigen: command not found /bin/sh: line 2: vppapigen: command not found So, yeah, installing ccache clears all that up. And since using vppapigen is sort of necessary for the whole build here, using ccache is not really an optional build-time dependency anymore. If you're cools with that, I'm cool with that, but we should list it as a build-time requirement for all build hosts including CentOS: $ git grep ccache Makefile Makefile:CCACHE_DIR?=$(BR)/.ccache Makefile:DEB_DEPENDS = curl build-essential autoconf automake ccache Makefile:RPM_SUSE_BUILDTOOLS_DEPS = autoconf automake ccache check-devel chrpath If no one beats me to it, I might submit a patch to help the situation. So it's a tie! jdl
[vpp-dev] vppsb's librtnl is broken with top of VPP tree
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.
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
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
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
On Wed, Feb 28, 2018 at 5:59 PM, Jon Loeliger 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
[vpp-dev] Tap and Tap-inject
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. A simplistic approach would start with the tried-and-true invocation of VPP using an interactive unix clause. For those not in the know, who suspect an arcane craft is at work, the following could be used: $ vppctl unix { interactive cli-listen /run/vpp/cli.sock gid vpp } Lo! The hidden messages are quick to appear! Some of the most unusual are these: 0: tap_inject_is_config_enabled:140: tap_inject_is_config_enabled: Value of im->flags is 0 0: tap_inject_sw_interface_add_del:706: tap_inject_sw_interface_add_del: tap_inject is disabled in config The astute would be quick to see that the messages appear for each interface configured on the system. And that they pertain to the mysteries at hand: Tap-injection. To verify that all is well, invoke the powerful VPP controller and create a tap! vpp# create tap host-if-name bob id 23 0: tap_inject_is_config_enabled:140: tap_inject_is_config_enabled: Value of im->flags is 0 0: tap_inject_sw_interface_add_del:706: tap_inject_sw_interface_add_del: tap_inject is disabled in config vpp# As if my magic call-backs, the same messages appear again on the VPP console. Do not be lured into a false sense of security, believing all is puppies and pink unicorns. There is hidden woe here. And here is the ominous part. Enable tap-inject. All should be well, right? All the taps and tap-derivatives should be aware and pleased with each other. But no. vpp# enable tap-inject Argh! Ho. Ly. Cow! There are more hidden messages! A lot! 0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 1 0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for sw_if_index 1 0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 1 thread 0 fd 35 0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 35 for thread 0 0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware address : 0:8:162:11:33:50 0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 401 0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index 1 tap_fd 35 tap_if_index 401 thread 0 0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 2 0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for sw_if_index 2 0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 2 thread 0 fd 36 0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 36 for thread 0 0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware address : 0:8:162:11:33:51 0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 402 0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index 2 tap_fd 36 tap_if_index 402 thread 0 0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 3 0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for sw_if_index 3 0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 3 thread 0 fd 37 0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 37 for thread 0 0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware address : 0:8:162:11:33:52 0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 403 0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index 3 tap_fd 37 tap_if_index 403 thread 0 0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 4 0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for sw_if_index 4 0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 4 thread 0 fd 38 0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 38 for thread 0 0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware address : 0:8:162:11:33:53 0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 404 0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index 4 tap_fd 38 tap_if_index 404 thread 0 0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 5 0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for sw_if_index 5 0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 5 thread 0 fd 39 0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 39 for thread 0 0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware address : 2:254:145:56:99:30 0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 405 0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index 5 tap_fd 39 tap_if_index 405 thread 0 But that i
Re: [vpp-dev] Upcoming memif API and CLI changes.
Peter, On Tue, Feb 27, 2018 at 11:09 AM, Jon Loeliger wrote: > Peter, > > 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 > Indeed this was a bug in the VAT call to that API function. I have submitted the patch: https://gerrit.fd.io/r/#/c/10848/ to address this issue. Thank you! jdl ._,_. Tt
Re: [vpp-dev] Upcoming memif API and CLI changes.
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
Re: [vpp-dev] VXLAN Instances Not Freed Properly?
On Fri, Feb 23, 2018 at 4:43 PM, John Lo (loj) wrote: > Hi Jon, > > > > I see the problem in the delete path where the hash_unset() call is using > the tunnel instance instead of the user_instance of the tunnel starting at > about line 558 of vxlan.c: > > > > vnet_delete_hw_interface (vnm, t->hw_if_index); > > hash_unset (vxm->instance_used, instance); > Woah. Awesome. > Do you mind submit a patch to fix it, please? > Will do! > Regards, > > John > Thanks, jdl
[vpp-dev] VXLAN Instances Not Freed Properly?
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
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
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
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
On Mon, Feb 5, 2018 at 9:55 AM, Jon Loeliger 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
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 = &vhost_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
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