aboutsummaryrefslogtreecommitdiffstats
path: root/vnet/vnet/lisp-cp/lisp_types.c
AgeCommit message (Collapse)AuthorFilesLines
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-1574/+0
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-06Fix length in LCAF headerFilip Tehlar1-1/+1
Change-Id: I56461c5d892ce223d1160fb57313ca1c51db9a23 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-12-06Implement LISP control plane messagesFilip Tehlar1-0/+51
* Map-register * Map-notify * RLOC probing Change-Id: I7f6295376b21cd67805446dfd1c1033acead2d4b Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-10-14FIB2.0: Adjacency complete pull model (VPP-487)Neale Ranns1-1/+31
Change the adjacency completion model to pull not push. A complete adjacency has a rewirte string, an incomplete one does not. the re-write string for a peer comes either from a discovery protocol (i.e. ARP/ND) or can be directly derived from the link type (i.e. GRE tunnels). Which method it is, is interface type specific. For each packet type sent on a link to a peer there is a corresponding adjacency. For example, if there is a peer 10.0.0.1 on Eth0 and we need to send to it IPv4 and MPLS packets, there will be two adjacencies; one for the IPv4 and one for the MPLS packets. The adjacencies are thus distinguished by the packets the carry, this is known as the adjacency's 'link-type'. It is not an L3 packet type, since the adjacency can have a link type of Ethernet (for L2 over GRE). The discovery protocols are not aware of all the link types required - only the FIB is. the FIB will create adjacencies as and when they are required, and it is thus then desirable to 'pull' from the discovery protocol the re-write required. The alternative (that we have now) is that the discovery protocol pushes (i.e. creates) adjacencies for each link type - this creates more adjacencies than we need. To pull, FIB now requests from the interface-type to 'complete' the adjacency. The interface can then delegate to the discovery protocol (on ethernet links) or directly build the re-write (i.e on GRE). Change-Id: I61451789ae03f26b1012d8d6524007b769b6c6ee Signed-off-by: Neale Ranns <nranns@cisco.com>
2016-09-27LISP Source/Dest control plane support, VPP-197Florin Coras1-4/+40
Change-Id: If88e4161e0944b657e6183b7b44348f7f46ba0a8 Signed-off-by: Florin Coras <fcoras@cisco.com> Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-09-21A Protocol Independent Hierarchical FIB (VPP-352)Neale Ranns1-5/+31
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-376: Refactor LISP dump API + VATFilip Tehlar1-0/+1
- refactor VAT so it won't cache data - remove unused filter flag from locator dump API call - json structure changed for locator and EID table dump calls - remote mapping VAT cli now accepts string for negative mapping action Change-Id: I776fb50659aaa7e98ad93715d282a83f78287344 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-08-17VPP-260 Coding standards cleanup - vnet/vnet/lisp-cpFlorin Coras1-335/+334
Change-Id: I29b84c44c12ab746e9e61c30efa0ac3418d1a09a Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-04VPP-197: LISP Source/Dest control plane supportFilip Tehlar1-66/+408
Change-Id: I0db53af96b925ec0d975dd77f471804b61351aec Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-08-04LISP multihoming API changes and cleanupFlorin Coras1-3/+2
Change-Id: I106352a6da0fad2b91dc8593f8d6d664af3113a8 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-08-03LISP API/VAT cleanupFlorin Coras1-0/+6
- 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-08-01Fix new LISP Coverity warningsFlorin Coras1-5/+3
Change-Id: I60ef5218110e596f77d11e3949284a7a7af7dedb Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-07-31Initial L2 LISP supportFlorin Coras1-6/+6
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-07-29LISP - fix bug in ip_prefix_normalize_ip6Andrej Kozemcak1-41/+57
- fix bug - refactoring code Change-Id: I2c330f3fbdead567b65c889cfffc2562d99b61db Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
2016-07-28LISP - Bug fix, can`t remove static remote mappingAndrej Kozemcak1-2/+75
Fix bug, can`t remove static remote mapping, small update in LISP remote mapping API. Change-Id: Ide32485a1a0d2cf08829d544500fa2755214b8cc Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
2016-07-21Fix CLI for adding LISP fwd entriesFlorin Coras1-14/+43
Change-Id: Ib707d252e624e3c1c4ac261fd3cef17b097633e5 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-07-07Add an option to dump details about specific LISP EID in API/CLIFilip Tehlar1-4/+24
Change-Id: Ie5e6751fd791e7ca728522632332abe442a1a75b Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-07-04LISP CP cleanup and refactoringFlorin Coras1-0/+2
- avoid code duplication by using only one function for insertion/updating of remote mappings into map-cache. Static remote mappings are now inserted using this function as well and therefore the code does not try to build forwarding entries out of them now. - bring up lisp dp interfaces when a vni is bound to a vrf. - ensure eids are cleaned-up before parsing control plane messages - ensure map-requests are always sent to default fib - new API to insert lisp adjacencies as opposed to remote mappings which should be replaced post merged in CSIT - reorganize and group functions according to their purpose and use. No need to pre-declare internal functions now. - this does not touch locator-set logic Change-Id: Ibcfc0f2d9c1bc1c9eab6e83c1af1b4cf9302ac10 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-06-27Add MAC address support to LISP map-cacheFilip Tehlar1-0/+19
Change-Id: I80f05a222cb0f728ad2460efe33955e781b6849f Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-06-24Reformat output of lisp eid-table show command.Filip Tehlar1-0/+4
Example output: DBGvpp# sh lisp eid EID type locators [100] 6.0.2.0/24 local(ls1) host-intervpp1 [200] 6.0.2.0/24 local(ls2) host-intervpp1 [100] 6.0.4.0/24 remote 6.0.3.2 [200] 6.0.99.0/24 local(ls3) local0 host-intervpp1 [0] 6.0.0.0/16 remote Change-Id: I69200bf7636167bce931def88828503a75496f4b Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-06-23LISP EID virtualization supportFilip Tehlar1-26/+71
Change-Id: I892c001cfdff9d8d93e646641d96520beb3c6265 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-06-22Add MAC address support for LISPFilip Tehlar1-6/+56
Change-Id: I79e3915fa61b497e6b586babcdf093937af07b2b Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-06-15Fix LISP locator pair selectionFlorin Coras1-0/+7
Make sure when selecting the local and remote locator pair for a data-plane tunnel that the local locator has a route, in the FIB, to the remote one. Change-Id: Idbc8a28a8ede786c11ef98cb18eba4a78c4a228e Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-05-11ONE-9: Fix clang build errorsFlorin Coras1-2/+2
Change-Id: Icbf3e269471ee0fc1d21f842b2ea220328a0f891 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-29Add support for LCAF Instance IDFilip Tehlar1-14/+338
Change-Id: Ifce3f2bdcba099157a42d0b694f3161b9f700ed2 Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-04-29Add lisp-gpe ip6 data-plane supportFlorin Coras1-0/+12
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-22Add clib_memcpy macro based on DPDK rte_memcpy implementationDamjan Marion1-6/+6
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-04-12Add unit test infrastructure for LISP protocolFilip Tehlar1-1/+11
Change-Id: I802700ad832de1dc6f4a1981e8985aa6e926c8ad Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
2016-04-02LISP GPE: initial CP commit and DP improvementsFlorin Coras1-0/+475
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>