summaryrefslogtreecommitdiffstats
path: root/src/vnet/l2
AgeCommit message (Collapse)AuthorFilesLines
2017-04-01CLI: create/delete bridge-domainChoonho Son2-1/+201
Added new CLI command - create bridge-domain <bridge-domain-id> - create bridge-domain <bridge-domain-id> del Change-Id: I1a7d632c7daa3c37b7f424a184e8fabd489518e9 Signed-off-by: Choonho Son <choonho.son@gmail.com>
2017-03-28Implement MAC Flush for BD or Interface from the L2FIBJohn Lo8-46/+253
Allow non-static MACs in the L2FIB which is associated with an interface or a bridge domain (BD) be flushed. MAC flush are initiated automatically when an interface is removed from a BD or when a BD is deleted. MAC flush can also be invoked manually via the following CLI: l2fib mac-flush interface <if-name> l2fib mac-flush bridge-domain <bd-id> Change-Id: Ie33243622834810a765f48ebcd22bdb8e8fc87a4 Signed-off-by: John Lo <loj@cisco.com>
2017-03-16vlib: make runtime_data thread-localDamjan Marion2-0/+31
Change-Id: I4aa3e7e42fb81211de1aed07dc7befee87a1e18b Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-03-07fix gcc 5.4 warning: argument to 'sizeof' in 'memcpy' call is the same ↵Gabriel Ganne2-10/+8
expression as the destination warning translates as an invalid write : sizeof(u8* b_dmac) == 8 != sizeof(eth_hdr->dst_address) == 6 ~/vpp/build-data/../src/vnet/l2/l2_vtr.c: In function 'l2pbb_get': ~/vpp/build-data/../src/vnet/l2/l2_vtr.c:734:63: error: argument to 'sizeof' in 'memcpy' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] ~/vpp/build-data/../src/vnet/l2/l2_vtr.c:736:63: error: argument to 'sizeof' in 'memcpy' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] update l2pbb_get to take an ethernet header instead of two u8* pointers for source and dest mac addresses. Change-Id: Ifcf1319a9e22614d57682f940e10f0420dc6fb8c Signed-off-by: Gabriel Ganne <gabriel.ganne@enea.com>
2017-03-03VPP-651: Ensure sw_if_index to node mapping for L2 output path is only done ↵Andrew Yourtchenko3-3/+17
via l2output_main.next_nodes Before this commit, several output features that happen to be the last in the list of features to be executed, send the packets directly to <interfaceName>-output. To do this, they use l2_output_dispatch, which builds a list of sw_if_index to next index mappings. When interfaces are deleted and the new interfaces are created, these mappings become stale, and cause the packets being sent to wrong interface output nodes. This patch (thanks John Lo for the brilliant idea!) adds a feature node "output", whose sole purpose is dispatching the packets to the correct interface output nodes. To do that, it uses the l2output_main.next_nodes, which is already taken care of for the case of the sw_if_index reuse, so this makes the dependent features all work correctly. Since this changes the packet path, for the features that were always the last ones it has triggered a side problem of the output feat_next_node_index not being properly initalized. These two users are l2-output-classify node and the output nodes belonging to the acl-plugin. For the first one the less invasive fix is just to initialize that field. For the acl-plugin nodes, rewrite the affected part of the code to use feat_bitmap_get_next_node_index since this is essentially what the conditional in l2_output_dispatch does, and fix the compiler warnings generated. This fix was first made in stable/1701 under commit e7dcee4027854b0ad076101471afdfff67eb9011. Change-Id: I32e876ab1e1d498cf0854c19c6318dcf59a93805 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2017-03-02Clean up binary api message handler registration issuesDave Barach1-22/+0
Removed a fair number of "BUG" message handlers, due to conflicts with actual message handlers in api_format.c. Vpp itself had no business receiving certain messages, up to the point where we started building in relevant code from vpp_api_test. Eliminated all but one duplicate registration complaint. That one needs attention from the vxlan team since the duplicated handlers have diverged. Change-Id: Iafce5429d2f906270643b4ea5f0130e20beb4d1d Signed-off-by: Dave Barach <dave@barachs.net>
2017-03-02bridge domain: fix members reordered when removingEyal Bari1-1/+1
since adding support for multicast vxlan flooding (flood class tunnel master) correct flood functionality depends on the order of the memebers vector solved by using vec_delete instead of vec_del1 which swaps members before deleting the last element Change-Id: I234f218d49172b4142c567db9699a5cb274e4a66 Signed-off-by: Eyal Bari <ebari@cisco.com>
2017-02-28Clear L2 output config on interface mode change to L3 (VPP-651)John Lo1-4/+11
With VPP-651, the L2 output config with L2-tag rewrite was not cleared when a sub-interface is deleted. Subsequently, when the same sw_if_index was reused for another interface, the L2 output config with L2-tag rewrite remained on the new interface. On deleting a (sub-)interface which is in L2 mode, it will be changed to L3 mode first to clear any L2 config. The L2 to L3 mode change path did address L2 input config cleanup. It is now fixed to also clear L2 output config. Change-Id: I3352a89d92e1b27340a5adcf75bbaa01a5050c29 Signed-off-by: John Lo <loj@cisco.com>
2017-02-22VPP-635: CLI Memory leak with invalid parameterBilly McFall2-15/+45
In the CLI parsing, below is a common pattern: /* Get a line of input. */ if (!unformat_user (input, unformat_line_input, line_input)) return 0; while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT) { if (unformat (line_input, "x")) x = 1; : else return clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); } unformat_free (line_input); The 'else' returns if an unknown string is encountered. There a memory leak because the 'unformat_free(line_input)' is not called. There is a large number of instances of this pattern. Replaced the previous pattern with: /* Get a line of input. */ if (!unformat_user (input, unformat_line_input, line_input)) return 0; while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT) { if (unformat (line_input, "x")) x = 1; : else { error = clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); goto done: } } /* ...Remaining code... */ done: unformat_free (line_input); return error; } In multiple files, 'unformat_free (line_input);' was never called, so there was a memory leak whether an invalid string was entered or not. Also, there were multiple instance where: error = clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); used 'input' as the last parameter instead of 'line_input'. The result is that output did not contain the substring in error, instead just an empty string. Fixed all of those as well. There are a lot of file, and very mind numbing work, so tried to keep it to a pattern to avoid mistakes. Change-Id: I8902f0c32a47dd7fb3bb3471a89818571702f1d2 Signed-off-by: Billy McFall <bmcfall@redhat.com> Signed-off-by: Dave Barach <dave@barachs.net>
2017-02-21VPP-540 : pbb tag rewrite detailsPavel Kotucek3-52/+140
Extended sw_interface_dump to provide 802.1ah (pbb) tag rewrite info if present. Extended log "l2-output" to provide raw data to display result of prospetive pbb tag rewrite. Tracing is moved after l2output_vtr to show these changes. Change-Id: I8b7cb865dc67ce21afab402cc086dac35f7c0f07 Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
2017-02-17l2 input: avoid per-packet trace checks in the fast pathDave Barach4-25/+54
Change-Id: Ib0c8572773499d8dd4d81b3a565c24412ccc3510 Signed-off-by: Dave Barach <dave@barachs.net>
2017-01-27API refactoring : l2 (add)Pavel Kotucek2-1/+147
Change-Id: I693a73ba9a5e3b0cb5d2a6c5d363f671e19c1f24 Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
2017-01-10API refactoring : l2, mpls, srPavel Kotucek2-3/+599
Change-Id: Ic5f273dae607a1d3902489e65734c76f027dc30f Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion37-0/+13596
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>