aboutsummaryrefslogtreecommitdiffstats
path: root/vnet/vnet/ip/udp.h
AgeCommit message (Collapse)AuthorFilesLines
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-313/+0
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-09Coding standards cleanup for vnet/vnet/ip, VPP-255Dave Barach1-72/+89
Change-Id: I12892fa571cc50e0541d6463a8b68e1b618edd9f Signed-off-by: Dave Barach <dave@barachs.net>
2016-12-07BFD: basic asynchronous session up/downKlement Sekera1-0/+2
This is a work-in-progress basic BFD session handling. Only asynchronous mode is supported at the moment. Setting the session flags doesn't work. Change-Id: Idba27f721b5c35be5a66a6d202a63d23ff7ecf6f Signed-off-by: Klement Sekera <ksekera@cisco.com>
2016-11-16Add an ability to punt all unknown UDP traffic to the hostAlexander Popovsky (apopovsk)1-0/+2
By default, VPP replies with ICMP error: port unreachable when receives an ‘unknown’ UDP (destination port with no registered listener) packet. An existing punt() API is extended to accept ALL (~0) as a L4 port number and if used redirects all ‘unknown’ UDP packets to the host. New ‘all’ option is added to the “set punt udp” CLI as well. Change-Id: I444fc5e32ffa3f0f085bb17708bf32b883ba09df Signed-off-by: Alexander Popovsky (apopovsk) <apopovsk@cisco.com>
2016-09-21A Protocol Independent Hierarchical FIB (VPP-352)Neale Ranns1-9/+29
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-05-25Add Vxlan-Gpe over IPv6Hongjun Ni1-0/+1
PatchSet4: consolidate code as per comments. PatchSet3: simplify the code using ip_udp_encap_one/two PatchSet2: consolidate comments and indent style Change-Id: Ia8b43f854a46d77e838e198566200ad28fd72472 Signed-off-by: Hongjun Ni <hongjun.ni@intel.com>
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>