aboutsummaryrefslogtreecommitdiffstats
path: root/vnet/vnet/ip/udp.h
AgeCommit message (Collapse)AuthorFilesLines
2016-04-29Fix ip-udp encap checksum for ip6Florin Coras1-0/+20
Thanks to Chris Luke for reporting. Change-Id: I4f2ac5bb0eb565738755ddb00e8c918134ff67b6 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-29Add lisp-gpe ip6 data-plane supportFlorin Coras1-66/+115
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-28VXLAN over IPv6.Chris Luke1-0/+1
Refactors the VXLAN node to work with both IPv4 and IPv6 transports. There is a discussion thread for this change at https://lists.fd.io/pipermail/vpp-dev/2016-March/000279.html Note that this changes the binary configuration API to support both address families; each address uses the same memory for either address type and a flag to indicate which is in use. This also includes changes to the Java API to support both address families. The CLI and VAT syntax remains unchanged; the code detects whether an IPv4 or an IPv6 address was given. Configuration examples: IPv4 CLI: create vxlan tunnel src 192.168.1.1 dst 192.168.1.2 vni 10 encap-vrf-id 0 decap-next l2 IPv6 CLI: create vxlan tunnel src 2620:124:9000::1 dst 2620:124:9000::2 vni 16 encap-vrf-id 0 decap-next l2 IPv4 VAT: vxlan_add_del_tunnel src 192.168.1.1 dst 192.168.1.2 vni 10 encap-vrf-id 0 decap-next l2 IPv6 VAT: vxlan_add_del_tunnel src 2620:124:9000::1 dst 2620:124:9000::2 vni 16 encap-vrf-id 0 decap-next l2 TODO: The encap path is not as optimal as it could be. Change-Id: I87be8bf0501e0c9cd7e401be4542bb599f1b6e47 Signed-off-by: Chris Luke <chrisy@flirble.org>
2016-04-22Add clib_memcpy macro based on DPDK rte_memcpy implementationDamjan Marion1-12/+3
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-04-06Fix ip4 udp encap length typeFlorin Coras1-2/+2
Change-Id: If666cda99a5fd92e904898ced40bcf2b5ac2d3a5 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-02Fix DPDK check in udp.hFlorin Coras1-2/+2
Change-Id: I4734b248f512e223703d234d28542257af1a8074 Signed-off-by: Florin Coras <fcoras@cisco.com>
2016-04-02LISP GPE: initial CP commit and DP improvementsFlorin Coras1-1/+98
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>
2015-12-08Initial commit of vpp code.v1.0.0Ed Warnicke1-0/+113
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17 Signed-off-by: Ed Warnicke <eaw@cisco.com>