aboutsummaryrefslogtreecommitdiffstats
path: root/vnet/vnet/lisp-gpe/lisp_gpe.h
AgeCommit message (Collapse)AuthorFilesLines
2016-09-21A Protocol Independent Hierarchical FIB (VPP-352)Neale Ranns1-92/+140
Main Enhancements: - Protocol Independent FIB API - Hierarchical FIB entries. Dynamic recursive route resolution. - Extranet Support. - Integration of IP and MPLS forwarding. - Separation of FIB and Adjacency databases. - Data-Plane Object forwarding model. Change-Id: I52dc815c0d0aa8b493e3cf6b978568f3cc82296c Signed-off-by: Neale Ranns <nranns@cisco.com>
2016-09-13VPP-292 Document vnet/vnet/lisp-gpeFlorin Coras1-40/+71
Change-Id: I5b282964330f4c14f7991453ee02c455a8d367ea Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-17VPP-261 Coding standards cleanup - vnet/vnet/lisp-gpeFlorin Coras1-48/+61
Change-Id: I1bc2098e79ce753f3d72f05f2fcac9ab00d0d052 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-11VPP-196 LISP L2/L3 tunnel multihomingFlorin Coras1-4/+32
Change-Id: If96d9ff23a7aacdb684494f854d4029f55837065 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-04LISP multihoming API changes and cleanupFlorin Coras1-10/+4
Change-Id: I106352a6da0fad2b91dc8593f8d6d664af3113a8 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-03LISP API/VAT cleanupFlorin Coras1-0/+3
- cleaned up some of the LISP APIs - added support for mac in dp APIs Change-Id: I11d419a30d73ddbf6554768d6dc2a09cc5a6e072 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-07-31Initial L2 LISP supportFlorin Coras1-34/+79
This introduces support for layer 2 overlays with LISP. Similarly to L3, all tenant packets to be encapsulated are captured by an interface, but the mapping (layer binding) instead of being between an L3 VRF and a LISP VNI, it is between and an L2 bridge domain and a VNI. At a high level, this results in two important properties: 1) the source and destinations of all packets flooded in the bridge-domain are mapped via the LISP control plane and the replies are converted into data-plane tunnels tracked via a LISP specific source/dest L2 FIB 2) All packets reaching the interface and matching a source/dest L2 LISP FIB entry are L3 (IP4/6) encapsulated. This is solely a unicast feature, therefore at this time ARPs are not handled in any special way. Change-Id: I0b7badcd7c6d5166db07d4acd2cc4ae7fba3e18e Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-06-21Check if LISP is enableAndrej Kozemcak1-1/+1
Lisp enable flag is enforced. DP API should not be call if the dp is disable. Change-Id: I265cf3ea0460987f3fd5fd84b43127dd3b1c43c3 Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
2016-05-10ONE-4: Add LISP enable/disable API/CLIFilip Tehlar1-0/+2
This patch adds an enable/disable API/CLI for control plane which calls similar functions for data plane. When re-enabling it also re-populates dataplane with tunnels and interfaces. Change-Id: Id8c3d6af90ecc0be331d502756914b1f62824046 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-05-09ONE-5: Remove unused vnet_lisp_gpe_add_del_tunnel APIFlorin Coras1-23/+14
Change-Id: Ib22ec807d2b74b7c3cb37f66052cd07bc4d896db Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-05-05ONE-2: Add new LISP dump API for lisp gpeAndrej Kozemcak1-0/+3
API: lisp_gpe_enable_disable_dump Change-Id: I1c8e78f00f9a3f99c1f2f54884af565292e4ccf8 Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
2016-04-29Add lisp-gpe ip6 data-plane supportFlorin Coras1-23/+76
The implementation mimics that of the ip4 data-plane. Therefore, a new lgpe-ip6-lookup lookup node is introduced for ip6 source lookups, a lisp-gpe-ip6-input node for decapsulating ip6 encapsulated packets and the tx function of the lisp-gpe interface is updated to support any mix of v4 and v6 in underlay and overlay. Change-Id: Ib3a6e339b8cd7618a940acf0dd8e61c042fd83dd Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-25Convert lisp-gpe encap to interface tx nodeFlorin Coras1-11/+25
With this change, one lisp-gpe interface is created per vrf/overlay tenant and its tx node is used as encapsulator (or tunnel ingress). For all intents and purposes, the tx node inherits all functions previously performed by the lisp-gpe-encap node and it maintains said node's position in lisp-gpe's data-path graph. Chiefly, this opens the possibility to chain interface features, like IPSec, transparently with LISP. Furthermore, it brings basic data plane support for vrfs and LISP instance-ids (or virtual network instances as per RFC7364). Other changes include improvements to lisp-gpe enable and disable sequences and corresponding API/VAT fixes. Change-Id: I085500450660a976b587b1a720e282f6e728d580 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-02LISP GPE: initial CP commit and DP improvementsFlorin Coras1-26/+96
Control Plane ------------- In essence, this introduces basic support for map-request/reply processing, the logic to generate and consume such messages, including SMRs, a control-plane backend, consisting of an eid-table, locator and locator-set tables, and CLI to interact with it. Naturally, we can now serialize/deserialize LISP specific types: addresses, locators, mappings, messages. An important caveat is that IPv6 support is not complete, both for EIDs and RLOCs. Functionally, the DP forwards all packets it can't handle to the CP (lisp_cp_lookup node) which takes care of obtaining a mapping for the packet's destination from a pre-configured map-resolver using the LISP protocol. The CP then caches this information and programs the DP such that all new packets with the same destination (or within the covering prefix) are encapsulated to one of the locators retrieved in the mapping. Ingress traffic-engineering is not yet supported. Data Plane ---------- First of all, to enable punting to the CP, when LISP GPE is turned on a default route that points to lisp_cp_lookup is now inserted. The DP also exposes an API the CP can use to program forwarding for a given mapping. This mainly consists in allocating a tunnel and programming the FIB such that all packets destined to the mapping's prefix are forwarded to a lisp-gpe encapsulating node. Another important change done for lisp forwarding is that both source and destination IP addresses are considered when encapsulating a packet. To this end, a new FIB/mtrie is introduced as a second stage, src lookup, post dst lookup. The latter is still done in the IP FIB but for source-dest entries, in the dest adjacency the lookup_next_index points to a lisp lookup node and the rewrite_header.sw_if_index points to the src FIB. This is read by the lisp lookup node which then walks the src mtrie, finds the associated adjacency, marks the buffer with the index and forwards the packet to the appropriate next node (typically, lisp-gpe-encap). Change-Id: Ibdf52fdc1f89311854621403ccdd66f90e2522fd Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-03-14fix declaration of symbol of different sizeJean-Mickael Guerin1-2/+2
I got many warnings at the link step with gcc version 5.3.1 20160225 (Ubuntu 5.3.1-10ubuntu2): /usr/bin/ld: Warning: size of symbol `cop_input_node' changed from 112 in vnet/cop/.libs/cop.o to 168 in vnet/cop/.libs/node1.o /usr/bin/ld: Warning: size of symbol `ethernet_input_node' changed from 112 in vnet/.libs/interface.o to 136 in vnet/ethernet/.libs/node.o /usr/bin/ld: Warning: size of symbol `l2output_node' changed from 112 in vnet/l2/.libs/l2_efp_filter.o to 120 in vnet/l2/.libs/l2_output.o /usr/bin/ld: Warning: size of symbol `srp_input_node' changed from 112 in vnet/srp/.libs/format.o to 136 in vnet/srp/.libs/node.o /usr/bin/ld: Warning: size of symbol `vxlan_encap_node' changed from 112 in vnet/vxlan/.libs/vxlan.o to 128 in vnet/vxlan/.libs/encap.o /usr/bin/ld: Warning: size of symbol `vxlan_input_node' changed from 112 in vnet/vxlan/.libs/vxlan.o to 144 in vnet/vxlan/.libs/decap.o ... Looking at vlib_node_registration_t, I think the reason is that the char * next_nodes[] could be bigger where the variable is defined in .c file. We should mark global variables as external in header files. Some of them can be made static. Change-Id: Ieb6961fd08180c9a69e1d884852703f3eb23f23f Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
2015-12-08Initial commit of vpp code.Ed Warnicke1-0/+137
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17 Signed-off-by: Ed Warnicke <eaw@cisco.com>